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 · 11 comments
Closed

Simplify Windows to/from IANA conversion methods #274

GoogleCodeExporter opened this issue Mar 15, 2015 · 11 comments
Milestone

Comments

@GoogleCodeExporter
Copy link

@GoogleCodeExporter GoogleCodeExporter 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
Copy link
Author

@GoogleCodeExporter GoogleCodeExporter 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

Loading

@GoogleCodeExporter
Copy link
Author

@GoogleCodeExporter GoogleCodeExporter 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

Loading

@GoogleCodeExporter
Copy link
Author

@GoogleCodeExporter GoogleCodeExporter 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

Loading

@GoogleCodeExporter
Copy link
Author

@GoogleCodeExporter GoogleCodeExporter 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

Loading

@GoogleCodeExporter
Copy link
Author

@GoogleCodeExporter GoogleCodeExporter 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

Loading

@GoogleCodeExporter
Copy link
Author

@GoogleCodeExporter GoogleCodeExporter 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

Loading

@malcolmr malcolmr added this to the 2.0-consider milestone Mar 15, 2015
@jskeet jskeet added this to the unscheduled milestone Nov 24, 2016
@jskeet jskeet removed this from the 2.0-consider milestone Nov 24, 2016
@jskeet
Copy link
Member

@jskeet jskeet commented Nov 24, 2016

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

Loading

@jskeet
Copy link
Member

@jskeet jskeet 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.

Loading

jskeet added a commit to jskeet/nodatime that referenced this issue Apr 19, 2019
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
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
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
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
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
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
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
These are canonicalized, and handle cases such as an alias being present but not the canonical ID, or vice versa.

Fixes nodatime#274
@robloo
Copy link

@robloo robloo commented Dec 2, 2019

Since this is being done, could you support the obsolete windows time zones with a hard-coded value? Just bringing this up again as it might be relevant to #778

Although, you could add some special code to handle the two given cases:

Kamchatka Standard Time (UTC+12:00) Petropavlovsk-Kamchatsky - Old
Mid-Atlantic Standard Time (UTC-02:00) Mid-Atlantic - Old

#778 (comment)

Loading

@jskeet
Copy link
Member

@jskeet jskeet commented Dec 3, 2019

@robloo: No, I definitely don't want to hard-code anything in the Noda Time codebase itself. If I were to do anything, it would have to be in the data file. But again, I don't think it's worth the complexity - I think it's best if you put that into your app logic instead.

Loading

@robloo
Copy link

@robloo robloo commented Dec 3, 2019

@jskeet Ok, fair enough. Seems I'm the only one concerned about this :)

Loading

@malcolmr malcolmr removed this from the unscheduled milestone May 21, 2020
@malcolmr malcolmr added this to the 3.0 milestone May 21, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants