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.