L
Laurence Neville
This is regarding a change in the Short Date format under Hebrew Regional
Settings, that has caused huge problems in our ASP web application. The
change appears to have been introduced sometime before Windows 2000 Service
Pack 4 and has remained through to Windows XP. I am looking for a solution
that doesn't involve rewriting our application (much) and that allows all
our users to keep using Hebrew Regional Settings.
To summarize our problem - we have an ASP-based intranet web application
that is used in our Israel office. Before we installed Windows 2000 SP4 on
our web server and on the client machines in the office, the application ran
perfectly. Dates appeared on the pages and in input textboxes in the correct
dd/mm/yyyy format. Immediately after installing SP4, dates on the pages and
in input textboxes are formatted as yyyy/mm/dd. This is not just a visual
change, it has caused many functions in the application to break.
No change was made in the Control Panel Regional Options on the clients or
server. In fact if you look there, when Hebrew is chosen, the short date
format on the Date tab is set to dd/mm/yyyy.
We have pinned the problem down to residing in the vbShortDate argument with
the VBScript function FormatDateTime. Following the installation of SP4, RTL
control characters are inserted (unicode character 8207) after each date
separator (/) in the date returned.
I am certain that this is a bug with windows, or a badly implemented new
'feature'. Suppose we're working with the date January 20, 2004 and the
serverside ASP code is returning exactly this (unformatted):
20/01/2004 1:00:00
When we format the date using FormatDateTime(datevalue, vbGeneralDate) we
get this (the exact same thing):
20/01/2004 1:00:00
However, when we format the date using FormatDateTime(datevalue,
vbShortDate) we get this:
[Char8207]20/[Char8207]01/[Char8207]2004
This translates to display (inside an input field in internet explorer) to:
2004/01/20, although the date is really being written as the line above,
i.e. [Char8207]20/[Char8207]01/[Char8207]2004. Internet Explorer is writing
the date to the screen correctly, but the control characters that the
formatdatetime function using vbshortdate argument are inserting are
rearranging the display.
The reason this is such a big problem is that other ASP functions that
process dates do not recognise these dates that include the control
characters as valid. If we use the IsDate function on the output of
FormatDateTime("20/1/2004", vbShortDate) the result is FALSE (because the
control characters exist).
Does anyone know of a permanent solution to this problem that doesn't
involve rewriting our application (much) and that allows all our users to
keep using Hebrew Regional Settings?
Settings, that has caused huge problems in our ASP web application. The
change appears to have been introduced sometime before Windows 2000 Service
Pack 4 and has remained through to Windows XP. I am looking for a solution
that doesn't involve rewriting our application (much) and that allows all
our users to keep using Hebrew Regional Settings.
To summarize our problem - we have an ASP-based intranet web application
that is used in our Israel office. Before we installed Windows 2000 SP4 on
our web server and on the client machines in the office, the application ran
perfectly. Dates appeared on the pages and in input textboxes in the correct
dd/mm/yyyy format. Immediately after installing SP4, dates on the pages and
in input textboxes are formatted as yyyy/mm/dd. This is not just a visual
change, it has caused many functions in the application to break.
No change was made in the Control Panel Regional Options on the clients or
server. In fact if you look there, when Hebrew is chosen, the short date
format on the Date tab is set to dd/mm/yyyy.
We have pinned the problem down to residing in the vbShortDate argument with
the VBScript function FormatDateTime. Following the installation of SP4, RTL
control characters are inserted (unicode character 8207) after each date
separator (/) in the date returned.
I am certain that this is a bug with windows, or a badly implemented new
'feature'. Suppose we're working with the date January 20, 2004 and the
serverside ASP code is returning exactly this (unformatted):
20/01/2004 1:00:00
When we format the date using FormatDateTime(datevalue, vbGeneralDate) we
get this (the exact same thing):
20/01/2004 1:00:00
However, when we format the date using FormatDateTime(datevalue,
vbShortDate) we get this:
[Char8207]20/[Char8207]01/[Char8207]2004
This translates to display (inside an input field in internet explorer) to:
2004/01/20, although the date is really being written as the line above,
i.e. [Char8207]20/[Char8207]01/[Char8207]2004. Internet Explorer is writing
the date to the screen correctly, but the control characters that the
formatdatetime function using vbshortdate argument are inserting are
rearranging the display.
The reason this is such a big problem is that other ASP functions that
process dates do not recognise these dates that include the control
characters as valid. If we use the IsDate function on the output of
FormatDateTime("20/1/2004", vbShortDate) the result is FALSE (because the
control characters exist).
Does anyone know of a permanent solution to this problem that doesn't
involve rewriting our application (much) and that allows all our users to
keep using Hebrew Regional Settings?