Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simplify Windows to/from IANA conversion methods #274

Closed
GoogleCodeExporter opened this issue Mar 15, 2015 · 8 comments · Fixed by #1393

Comments

@GoogleCodeExporter
Copy link

commented Mar 15, 2015

What situation does this request make simpler?
Since Noda Time contains IANA, Windows, and CLDR data, it can be used to 
convert BCL time zones to or from TZDB time zones.  The data is exposed in the 
API, but sensible conversion methods aren't included.  This could be more 
convenient, such as illustrated here:
http://stackoverflow.com/a/17348822/634824

Can you provide a straw-man example of what you'd want the API to look
like?

string bclZoneId = 
TzdbDateTimeZoneSource.Default.WindowsMapping.TranslateToBcl(tzdbZoneId);

string tzdbZoneId = 
TzdbDateTimeZoneSource.Default.WindowsMapping.TranslateToTzdb(bclZoneId);


We could also consider (in addition) a new method to DateTimeZone with the 
signature:

public DateTimeZone TranslateFor(IDateTimeZoneProvider provider)

Which would give some convenience for those not used to calling into a the 
TzdbDateTimeSource, for example:

DateTimeZone bclZone = 
DateTimeZoneProviders.Tzdb[tzdbZoneId].TranslateFor(DateTimeZoneProviders.Bcl);

DateTimeZone tzdbZone = 
DateTimeZoneProviders.Bcl[bclZoneId].TranslateFor(DateTimeZoneProviders.Tzdb);




Original issue reported on code.google.com by mj1856 on 26 Mar 2014 at 6:08

@GoogleCodeExporter

This comment has been minimized.

Copy link
Author

commented Mar 15, 2015

I'd also be fine with TranslateWith or TranslateTo or similar naming.

Original comment by mj1856 on 26 Mar 2014 at 6:10

@GoogleCodeExporter

This comment has been minimized.

Copy link
Author

commented Mar 15, 2015

I would *hope* the PrimaryMapping dictionary in WindowsMapping always maps to 
canonical IDs - I'm adding a validation check for that (which will be executed 
when creating a new nzd file). I'll see if it works.

For the reverse mapping, I think I'd prefer to create a method which returns a 
reverse mapping as a dictionary... but I'm not sure yet. Still considering it.

I don't see how the DateTimeZone method could work - imagine that someone else 
has come up with a new IDateTimeZoneProvider... there's no way that a 
BCL-originated zone can know how to translate that. I think this is a 
sufficiently rare scenario that requiring that the caller uses 
TzdbDateTimeZoneSource is reasonable.

Original comment by jonathan.skeet on 29 Mar 2014 at 5:56

@GoogleCodeExporter

This comment has been minimized.

Copy link
Author

commented Mar 15, 2015

The CLDR data intentionally doesn't follow links.  They require stable 
identifiers in the mapping data.  See 
http://unicode.org/cldr/trac/ticket/6971#comment:2

If we expect PrimaryMapping to contain TZDB canonical IDs, instead of just 
representing the CLDR map, then we'd have to resolve them at time of import.

I see your point about supporting a TranslateFor method generically for any 
IDateTimeZoneProvider would be difficult.  I was just thinking about the two 
existing providers.

How likely do you think it is that other time zone providers would be used?  
The only one I can even think of off the top of my head is the IATA zones used 
by the FAA, but they're not so fully functional anyway.

Original comment by mj1856 on 30 Mar 2014 at 6:52

@GoogleCodeExporter

This comment has been minimized.

Copy link
Author

commented Mar 15, 2015

Please consider this or something like it for v2.0.  Thanks.

Original comment by mj1856 on 24 Jun 2014 at 4:02

@GoogleCodeExporter

This comment has been minimized.

Copy link
Author

commented Mar 15, 2015

Also, we may want to consider that we currently build the CanonicalIdMap by 
following TZDB links, but the CLDR and TZDB disagree on what is "canonical".

In the case of ZoneA changing names to ZoneB, the TZDB says that ZoneB is now 
canonical and makes ZoneA a link.

However, CLDR requires stable identifiers, so it would consider ZoneA to 
_always_ be the canonical ID - adding ZoneB as an alias.

See: http://unicode.org/cldr/trac/ticket/6971

The CLDR canonical maps are in 
http://www.unicode.org/repos/cldr/trunk/common/bcp47/timezone.xml

The first zone in the space-delimited list in the "alias" attribute is 
canonical by the CLDR.

Consider also that CLDR considers "Etc/GMT" to be canonical with "Etc/UTC" an 
alias, while TZDB considers each their own zone.  This requires an exception 
case in the mapping, as discussed here: 
http://stackoverflow.com/q/24394610/634824

I'm uncertain if there are any other exception cases like that one or not.


Original comment by mj1856 on 24 Jun 2014 at 8:59

@GoogleCodeExporter

This comment has been minimized.

Copy link
Author

commented Mar 15, 2015

fwiw, http://stackoverflow.com/a/25092899/1774334 could have done with a 
reverse dictionary/method.

Original comment by malcolm.rowe on 2 Aug 2014 at 8:55

  • Added labels: Type-Enhancement, Milestone-2.0-consider, Priority-Medium

@malcolmr malcolmr added this to the 2.0-consider milestone Mar 15, 2015

@jskeet jskeet modified the milestones: unscheduled, 2.0-consider Nov 24, 2016

@jskeet

This comment has been minimized.

Copy link
Member

commented Nov 24, 2016

We can add these later - it shouldn't block 2.0.

@jskeet

This comment has been minimized.

Copy link
Member

commented Apr 19, 2019

Time to finally do this, I think. Let's start with just the TranslateToBcl and TranslateToTzdb methods - things get really complicated if you put them on DateTimeZone, which doesn't currently know its source.

jskeet added a commit to jskeet/nodatime that referenced this issue Apr 19, 2019
Simplify mapping between Windows and TZDB time zone IDs
Fixes nodatime#274.

I'd be open to the idea of adding convenience methods to TzdbDateTimeZoneSource as well, that just pass through to WindowsZones, if that were considered useful.
jskeet added a commit to jskeet/nodatime that referenced this issue Apr 19, 2019
Simplify mapping between Windows and TZDB time zone IDs
Fixes nodatime#274.

I'd be open to the idea of adding convenience methods to TzdbDateTimeZoneSource as well, that just pass through to WindowsZones, if that were considered useful.
jskeet added a commit to jskeet/nodatime that referenced this issue Apr 21, 2019
Simplify mapping between Windows and TZDB time zone IDs
Fixes nodatime#274.

I'd be open to the idea of adding convenience methods to TzdbDateTimeZoneSource as well, that just pass through to WindowsZones, if that were considered useful.
jskeet added a commit to jskeet/nodatime that referenced this issue May 26, 2019
Provide dictionaries from TZDB ID to Windows ID and vice versa
These are canonicalized, and handle cases such as an alias being present but not the canonical ID, or vice versa.

Fixes nodatime#274
jskeet added a commit to jskeet/nodatime that referenced this issue May 26, 2019
Provide dictionaries from TZDB ID to Windows ID and vice versa
These are canonicalized, and handle cases such as an alias being present but not the canonical ID, or vice versa.

Fixes nodatime#274
jskeet added a commit to jskeet/nodatime that referenced this issue Jul 3, 2019
Provide dictionaries from TZDB ID to Windows ID and vice versa
These are canonicalized, and handle cases such as an alias being present but not the canonical ID, or vice versa.

Fixes nodatime#274

@jskeet jskeet closed this in #1393 Jul 3, 2019

jskeet added a commit that referenced this issue Jul 3, 2019
Provide dictionaries from TZDB ID to Windows ID and vice versa
These are canonicalized, and handle cases such as an alias being present but not the canonical ID, or vice versa.

Fixes #274
cuteant added a commit to cuteant/nodatime that referenced this issue Jul 3, 2019
Provide dictionaries from TZDB ID to Windows ID and vice versa
These are canonicalized, and handle cases such as an alias being present but not the canonical ID, or vice versa.

Fixes nodatime#274
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.