[Mono-dev] TimeZone/RegionInfo patches

[Atsushi Eno]

Hi,

>> 2) TZ environment variable support on Win32. If TZ environment
>> variable is set, then it uses posix-compat timezone names
>> (its behavior depends on mingw though).
> 
> I don't think that this is a good idea. Time zone is used to convert local
> time to UTC so if TZ contains a time zone other than that Windows uses you
> will assume wrong offset of local time and will get a wrong UTC value.
> 
> I have never used mingw but using TZ environment variable should be done
> only if mingw provides local time converted to TZ offset using it's own
> runtime functions instead of a local time based on the Windows time zone
> offset.

Mingw does provide TZ environment based timezone support, though
it is not good as we see today's Linux boxes (it does not support
e.g. "Asia/Tokyo", only "JST"). Mingw also seems using Windows
API if TZ settings are not avaiable, but it is precise POSIX
behavior (in such case default timezone is dependent on the system).

As I said, it is done "if TZ environment variable is set" and
otherwise it keeps using Windows API. TZ is not used by Windows.

However, if people can still debug TimeZone related things easily
without this mode, then it is OK for me.

>> 3) tiny change on RegionInfo.CurrentRegion to construct
>> apart from CultureInfo. In fact I have further patch to store
>> it inside Thread (as once Kornel suggested) but it is not
>> working perfectly now, so I just extracted minimal working part.
>> (This looks like independent but it shares a function with 1).
> 
> I never suggested to store current region inside Thread.:) Current region
> should be stored in a static field of RegionInfo and should be initialized
> when CurrentRegion is called for the first time and it should be the same
> inside the entire AppDomain until CultureInfo.ClearCachedData() is called
> that clear cached data that will be reinitialized when next time
> CurrentRegion is called.

Oh X-)

Well, then now I don't think we don't need any changes from the
existing RegioinInfo code at all. Current code uses static field to
store CurrentRegion, using the initial culture LCID which is
retrieved via Windows API (and nothing to do with *Current*Culture) .

If there is a proof of code that existing one is incorrect, then
I'd fix it.

> 4) And I think parsing locale name in get_current_locale_id is not required
> at least on Windows as it returns current locale as an LCID that currently
> is converted to a name then it is coverted back to and LCID.

Agreed. I added a tiny switch for PLATFORM_WIN32 in that function.

Atsushi Eno