Re: [Mono-dev] TimeZone/RegionInfo patches
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). ... However, if people can still debug TimeZone related things easily without this mode, then it is OK for me. Time zone can easly be changed in Control Panel without restart on all versions of Windows. Example screen shot: http://www.ssw.com.au/SSW/Standards/BetterSoftwareSuggestions/images/windows2.gif 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. The current code may be good, but at least has no basic problems. You posted a patch to the list in the recent past that mixed CurrentRegion with Thread the same thing you were talking about in this thread. That's why I tried to explain the expected behaviour of CurrentRegion. 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. That's good.:) Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] TimeZone/RegionInfo patches
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. 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. On Windows CurrentRegion and CurrentCulture sould be initialized based on the value of GetUserDefaultLCID as it may change without restart. CurrentUICulture should be initialized based on GetUserDefaultUILanguage. But after their singleton instance was created on the first query they should not be modified. On Posix some functionally equivalent value should be used. For more information: http://lists.ximian.com/pipermail/mono-devel-list/2005-August/014128.html 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. The functionality of the other parts looks OK to me. Kornél - Original Message - From: Atsushi Eno [EMAIL PROTECTED] To: mono-devel-list@lists.ximian.com Sent: Friday, September 16, 2005 7:30 AM Subject: [Mono-dev] TimeZone/RegionInfo patches Hi, I made a set of patches for a few globalization related stuff. 1) native TimeZone name support. Now it returns native names as long as they are provided by the locale-builder. Am also planning to update locale data to the latest version of CLDR (it has much more timezone names than existing one). 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). 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). Comments are welcome :-) Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] TimeZone/RegionInfo patches
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 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] TimeZone/RegionInfo patches
Hi,
I made a set of patches for a few globalization related stuff.
1) native TimeZone name support. Now it returns native names
as long as they are provided by the locale-builder.
Am also planning to update locale data to the latest version
of CLDR (it has much more timezone names than existing one).
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).
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).
Comments are welcome :-)
Atsushi Eno
Index: tools/locale-builder/Driver.cs
===
--- tools/locale-builder/Driver.cs (revision 50129)
+++ tools/locale-builder/Driver.cs (working copy)
@@ -48,6 +48,7 @@
private Hashtable langs;
private Hashtable currency_types;
private Hashtable regions;
+private ArrayList timezones;
// The lang is the language that display names will be displayed in
public string Lang {
@@ -82,6 +83,7 @@
langs = new Hashtable ();
cultures = new ArrayList ();
regions = new Hashtable ();
+timezones = new ArrayList ();
LookupRegions ();
@@ -116,6 +118,9 @@
ArrayList regionList = new ArrayList (regions.Values);
regionList.Sort (RegionComparer.Instance);
+
+ timezones.Sort (TimeZoneEntryComparer.Instance);
+
int number = 0;
foreach (RegionInfoEntry r in regionList)
r.RegionId = number++;
@@ -163,6 +168,7 @@
writer.WriteLine (#define NUM_CULTURE_ENTRIES + cultures.Count);
writer.WriteLine (#define NUM_REGION_ENTRIES + regionList.Count);
+writer.WriteLine (#define NUM_TIMEZONE_ENTRIES + timezones.Count);
writer.WriteLine (\n);
// Sort the cultures by lcid
@@ -245,6 +251,15 @@
writer.Write (builder);
writer.WriteLine (};\n\n);
+builder = new StringBuilder ();
+foreach (TimeZoneEntry ti in timezones) {
+ ti.AppendTableRow (builder);
+ builder.Append (,\n);
+}
+writer.WriteLine (static const TimeZoneEntry timezone_entries [] = {);
+writer.Write (builder);
+writer.WriteLine (NULL};\n\n);
+
builder = new StringBuilder ();
rcount = 0;
foreach (RegionInfoEntry ri in regionList) {
@@ -321,12 +336,44 @@
ci.DateTimeFormatEntry = null;
ci.NumberFormatEntry = null;
+ // TimeZones
+ XPathNodeIterator iter = doc.CreateNavigator ()
+.Select (/ldml/dates/timeZoneNames/zone);
+ while (iter.MoveNext ()) {
+nav = iter.Current;
+int lcid;
+try {
+ if (ci.SpecificLcid.StartsWith (0x))
+ lcid = int.Parse (ci.SpecificLcid.Substring (2), NumberStyles.HexNumber);
+ else
+ lcid = int.Parse (ci.SpecificLcid);
+} catch {
+ Console.WriteLine (Invalid LCID: '{0}', ci.SpecificLcid);
+ throw;
+}
+timezones.Add (new TimeZoneEntry (
+ lcid,
+ nav.GetAttribute (type, String.Empty),
+ EvaluateAsString (nav, long/standard/text()),
+ EvaluateAsString (nav, long/daylight/text()),
+ EvaluateAsString (nav, short/standard/text()),
+ EvaluateAsString (nav, short/daylight/text(;
+ }
+
langs [lang] = ci;
cultures.Add (ci);
return true;
}
+ private string EvaluateAsString (XPathNavigator nav, string xpath)
+ {
+ XPathNodeIterator i = nav.Select (xpath);
+ if (i.MoveNext ())
+return i.Current.Value;
+ return String.Empty;
+ }
+
private void ParseLocale (string locale)
{
CultureInfoEntry ci;
Index: tools/locale-builder/Makefile.am
===
--- tools/locale-builder/Makefile.am (revision 50129)
+++ tools/locale-builder/Makefile.am (working copy)
@@ -24,6 +24,7 @@
NumberFormatEntry.cs \
RegionInfoEntry.cs \
TextInfoEntry.cs \
+ TimeZoneEntry.cs \
Entry.cs
supp_data_files = supp/ar_AE.xml supp/ar_EG.xml supp/ar_KW.xml supp/ar_MA.xml \
Index: mono/metadata/culture-info-tables.h
===
--- mono/metadata/culture-info-tables.h (revision 50129)
+++ mono/metadata/culture-info-tables.h (working copy)
@@ -6,6 +6,7 @@
#define NUM_CULTURE_ENTRIES 161
#define NUM_REGION_ENTRIES 230
+#define NUM_TIMEZONE_ENTRIES 38
static
