MORE INFORMATION
Based on customer requirements, the manner in which the
Regional Settings (primarily the Date/Time format) are read from the system has
changed in recent versions of the operating system in order to provide
developers with more control of this feature.
Although the Regional
Settings function differently in each of the above-mentioned operating systems
(except Windows NT 4.0), they do have one common behavior: the Regional
Settings function the same in all operating system versions when no one is
physically logged on to the system.
How Date/Time is formatted when accessed from ASP
IIS 4.0 (Windows NT 4.0)
When no one is physically logged on to the server, IIS reads the
Date/Time format (and other Regional Settings) from the system default
settings, specifically from the Locale.nls file. You can change this setting in
the Regional Settings section of Control Panel, after which you must reboot the
computer.
When someone is logged on to the computer, IIS reads the
logged-on user's Regional Settings. These settings are read from the user
profile settings in the
HKEY_CURRENT_USER/Control Panel/International registry hive. You can change this setting in the Regional
Settings section of Control Panel, after which you must reboot the computer.
IIS 5.0 (Windows 2000 and Windows 2000 Service Pack 1)
During the operating system installation, the Regional Settings
options are specified and written to the system registry in the
HKEY_USERS/.Default/Control Panel/International hive.
In general, when an ASP page that displays the
Date/Time is requested, IIS first determines if the authenticating user's
profile is loaded in the registry. If it is, IIS reads the Locale ID for that
user profile and then looks in the IIS cache (if the Regional Settings for this
locale are cached). If cached, IIS serves the request with the cached format.
If the locale is not found in the cached values, the Date/Time format is read
from that user's profile settings in the
HKEY_CURRENT_USER/Control Panel/International registry hive. The information is then cached, and IIS displays
the ASP page with the cached Date/Time format.
If the authenticating
user does not have a user profile, IIS reads the Locale ID from the system
default settings and then looks for the cached Regional Settings for that
locale. If the cached values are found, IIS serves the request with the cached
format; otherwise, IIS reads the format from the system default settings in the
HKEY_USERS/.Default/Control Panel/International registry hive. The information is then cached, and IIS displays
the ASP page with the cached Date/Time format.
There is a problem
with this logic, however. For every request, IIS checks to see if the Date/Time
format is cached for the resulting Locale ID. If IIS finds a cached format, it
uses it. The problem occurs if the user who browses to this page first has a
Locale ID that is the same as the intended Locale ID to be used with an ASP
page, but their date format is different from the intended date format to be
used with an ASP page. In this situation, the cached date format for that
Locale ID is the wrong format and will be served to the rest of the users who
request this page.
When no user is physically logged on to the
server, IIS reads the Date/Time format, as well as other Regional Settings,
from the above registry location, not from the Locale.nls file as it does in
Windows NT 4.0.
IIS 5.0 (Windows 2000 Service Pack 2 and later)
In Windows 2000 Service Pack 2 (SP2), the default behavior is as
mentioned above. However, you can also customize the settings: you can either
change the base OLEAUT component or change IIS so that it can enable this
change in OLEAUT.
You can set the registry entry for OLEAUT globally.
This does not override a process that explicitly sets the option by using the
exposed call. Thus, if you set the following IIS value, you override the OLEAUT
setting.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\OLEAUT
VarConversionLocaleSetting = 0,1,2 (DWORD)
Note The OLEAUT key may not exist. If it does not, you must create the
key first.
You can also set the value for IIS, which also overrides
any global setting for OLEAUT. Moreover, IIS will call this OLEAUT application
programming interface (API) whether or not the registry entry is set.
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\InetInfo\Parameters
SetVarConversionLocaleSetting = 0,1,2 (DWORD)
The values of 0, 1, and 2 are the
same for OLEAUT and IIS and are defined as follows:
- 0 - The default behavior, as stated earlier. This format is
completely random. It is based on the last user or process that set the
cache.
- 1 - The format is based on the current identity of the
thread that requests these values (makes the call to the OLEAUT32.dll file). In
IIS, this is the authenticating user profile setting because IIS impersonates
the authenticating user by default. If the authenticating user's profile does
not exist or is not loaded into the registry, it defaults to the system default
settings from the HKEY_USERS\.default\Control Panel\International registry hive.
You can configure the Web application in
such a way that the impersonated user on a thread that requests these formats
can always be the same user; thus, you establish a consistent format. For
example, if you use anonymous access on an ASP page, the same date format is
returned, regardless of who is logged on to the system and which actual user is
requesting the page. - 2 - The format is forced to use the system default Regional
Settings. The system default settings are set for a computer at reboot. To
modify the default system settings, select a new locale and then click Set Default in the Regional Settings tool in Control Panel. You must restart
the computer for this change to take effect. In this case, the Date format is
not read from the registry but from the Locale.nls file for that
locale.
Note When you change the default locale, you change all Regional
Settings such as Currency, Time, and Date. There is no way to modify a specific
setting within the locale.
IIS 5.0 (ASP.NET)
The basic behavior and the fundamentals remain the same in
ASP.NET
1.0. For example, calls to the
Response.Write(Now()) and
Response.Write(Date()) functions still behave the same way as they do in classic ASP for
that operating system. However, there are special format functions in ASP.NET
to format the Date/Time and other cultural information. For more information,
see the MSDN documentation for
CultureInfo,
RegionInfo, and the
System.Globalization namespace. On a computer that is running Windows
2000 and where ASP.NET 1.1 is installed,
the user profile of the identity of the ASPNET process is loaded, and that
profile is used for regional settings.
Related information
If you want a Date/Time format for the locale that differs from
the system default locale, it is best to use the following code in an ASP page
to set the format:
<% Session.LCID=2058
'OR use the VBScript SetLocale function to set the locale.
Response.Write FormatDateTime( Now(), 2)
'The Constant 2 is for obtaining the vbShortDate.
%>
This article focuses mainly on the Date/Time format. The rest of the
Regional Settings may not behave in the same manner as the Date/Time format
because of the way IIS caches the Date/Time format. For example, the Currency
format also depends on the Regional Settings but follows the logic that is
specified with a setting of 1 in the "IIS 5.0 (Windows 2000 Service Pack 2 and
Later)" section.
Accessing the Date/Time format from a service such
as Internet Information Services (IIS) is different from how other stand-alone
processes (non-services) access it. In general, the Regional Settings for a
stand-alone program are accessed from the user profile of that application's
launching user, which is usually the same account as the logged-on
user.
Because the services run even when no one is logged on to the
computer, there must be a way to retrieve the Regional Settings when no user is
logged on to the computer. The system default settings in the
HKEY_USERS/.Default/Control Panel/International registry hive can retrieve the Regional Settings.
How
these Regional Settings are accessed depends on certain parameters when someone
is logged on to the system, and those behaviors vary for different operating
systems.