/nodatime

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

Provide more information on BCL time zone mappings #82

Closed
GoogleCodeExporter opened this Issue Mar 15, 2015 · 11 comments

Comments

Assignees
No one assigned
Labels
Projects
None yet
Milestone
  1.1.0
2 participants
@GoogleCodeExporter @malcolmr
@GoogleCodeExporter

GoogleCodeExporter commented Mar 15, 2015 

CLDR now providers a 1-to-many mapping from Windows names to TZDB IDs. We 
currently map the "default" territory of "001" but we could give more 
information... it probably should be part of work to bring in other information 
from CLDR.

(There's scope for a whole other project to make CLDR information more 
universally accessible and useful from a .NET environment, but hey...)

Original issue reported on code.google.com by jonathan.skeet on 12 Jul 2012 at 12:22

@GoogleCodeExporter GoogleCodeExporter added auto-migrated labels Mar 15, 2015

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 15, 2015

Original comment by malcolm.rowe on 13 Jul 2012 at 8:33

  • Added labels: Type-Enhancement

GoogleCodeExporter commented Mar 15, 2015

Original comment by malcolm.rowe on 13 Jul 2012 at 8:33

  • Added labels: Type-Enhancement
@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 15, 2015

Original comment by malcolm.rowe on 30 Jul 2012 at 7:47

  • Added labels: Milestone-1.1-consider
  • Removed labels: V1-OutOfScope

GoogleCodeExporter commented Mar 15, 2015

Original comment by malcolm.rowe on 30 Jul 2012 at 7:47

  • Added labels: Milestone-1.1-consider
  • Removed labels: V1-OutOfScope
@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 15, 2015 

Given that this is TZDB-specific, we can expose it on TzdbDateTimeZoneSource, 
as that's visible post issue 144.

(When we've looked at all the metaZone stuff, we could expose that in the same 
way...)

Original comment by jonathan.skeet on 11 Nov 2012 at 12:22

GoogleCodeExporter commented Mar 15, 2015 

Given that this is TZDB-specific, we can expose it on TzdbDateTimeZoneSource, 
as that's visible post issue 144.

(When we've looked at all the metaZone stuff, we could expose that in the same 
way...)

Original comment by jonathan.skeet on 11 Nov 2012 at 12:22
@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 15, 2015 

This is the relevant sections of the CLDR specification:
http://www.unicode.org/reports/tr35/#Timezone_Names
http://www.unicode.org/reports/tr35/#Time_Zone_Fallback
http://www.unicode.org/reports/tr35/#Supplemental_Timezone_Data

Also relevant:
http://www.rfc-editor.org/rfc/bcp/bcp47.txt


Trying to read through this makes me want to run away and cry. I suspect it 
will get better over time though.

Relevant files I've found, relative to the root of the core.zip CLDR data 
archive, in the "common" directory ('cos everything is...):

- bcp47/timezone.xml (May not be useful? Not sure yet.)
- main/*.xml (timezoneNames element for each language)
- supplemental/metaZones.xml
- supplemental/windowsZones.xml

Original comment by jonathan.skeet on 13 Nov 2012 at 9:21

GoogleCodeExporter commented Mar 15, 2015 

This is the relevant sections of the CLDR specification:
http://www.unicode.org/reports/tr35/#Timezone_Names
http://www.unicode.org/reports/tr35/#Time_Zone_Fallback
http://www.unicode.org/reports/tr35/#Supplemental_Timezone_Data

Also relevant:
http://www.rfc-editor.org/rfc/bcp/bcp47.txt


Trying to read through this makes me want to run away and cry. I suspect it 
will get better over time though.

Relevant files I've found, relative to the root of the core.zip CLDR data 
archive, in the "common" directory ('cos everything is...):

- bcp47/timezone.xml (May not be useful? Not sure yet.)
- main/*.xml (timezoneNames element for each language)
- supplemental/metaZones.xml
- supplemental/windowsZones.xml

Original comment by jonathan.skeet on 13 Nov 2012 at 9:21

@GoogleCodeExporter GoogleCodeExporter closed this Mar 15, 2015

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 15, 2015

Original comment by malcolm.rowe on 25 Jan 2013 at 8:32

  • Added labels: Milestone-1.3.0
  • Removed labels: Milestone-1.1-consider

GoogleCodeExporter commented Mar 15, 2015

Original comment by malcolm.rowe on 25 Jan 2013 at 8:32

  • Added labels: Milestone-1.3.0
  • Removed labels: Milestone-1.1-consider
@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 15, 2015 

I'm starting to wonder whether it wouldn't make sense to include all the 
information in the windows zone mapping file in version 1.1, while we're 
already making a clean break to a new file format. We don't need to expose it 
all right now, but we could build the current mapping in memory from the fuller 
information.

That way we won't need to either duplicate a field or worry about backward 
compatibility when we get to version 1.3.

I'll investigate how much space it would add (which is all wasted until we 
expose the information of course) and we can make a decision based on that.

Original comment by jonathan.skeet on 23 Feb 2013 at 9:04

  • Added labels: Milestone-1.1-consider
  • Removed labels: Milestone-1.3.0

GoogleCodeExporter commented Mar 15, 2015 

I'm starting to wonder whether it wouldn't make sense to include all the 
information in the windows zone mapping file in version 1.1, while we're 
already making a clean break to a new file format. We don't need to expose it 
all right now, but we could build the current mapping in memory from the fuller 
information.

That way we won't need to either duplicate a field or worry about backward 
compatibility when we get to version 1.3.

I'll investigate how much space it would add (which is all wasted until we 
expose the information of course) and we can make a decision based on that.

Original comment by jonathan.skeet on 23 Feb 2013 at 9:04

  • Added labels: Milestone-1.1-consider
  • Removed labels: Milestone-1.3.0
@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 15, 2015 

Looks like it only adds about 5K to the data, so I think it's worth doing 
sooner rather than later. We could actually expose it pretty easily, too (on 
TzdbDateTimeZoneSource) - it's just a matter of how "nicely" we want to do so.

Original comment by jonathan.skeet on 23 Feb 2013 at 10:23

GoogleCodeExporter commented Mar 15, 2015 

Looks like it only adds about 5K to the data, so I think it's worth doing 
sooner rather than later. We could actually expose it pretty easily, too (on 
TzdbDateTimeZoneSource) - it's just a matter of how "nicely" we want to do so.

Original comment by jonathan.skeet on 23 Feb 2013 at 10:23
@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 15, 2015 

More work than I'd expected to do it properly... but the change is now in a 
"CLDR Windows zones" branch.

A bit more testing required to include in 1.1, and a design review before we 
expose the information publicly (which might also be in 1.1).

Malcolm: this changes the stream format again, of course... so we should decide 
on it
soon, in order to potentially change the docs :)

Original comment by jonathan.skeet on 23 Feb 2013 at 5:36

  • Changed state: Started

GoogleCodeExporter commented Mar 15, 2015 

More work than I'd expected to do it properly... but the change is now in a 
"CLDR Windows zones" branch.

A bit more testing required to include in 1.1, and a design review before we 
expose the information publicly (which might also be in 1.1).

Malcolm: this changes the stream format again, of course... so we should decide 
on it
soon, in order to potentially change the docs :)

Original comment by jonathan.skeet on 23 Feb 2013 at 5:36

  • Changed state: Started
@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 15, 2015 

This is implemented, and will be reviewed as part of issue 173.

Original comment by jonathan.skeet on 21 Mar 2013 at 2:50

GoogleCodeExporter commented Mar 15, 2015 

This is implemented, and will be reviewed as part of issue 173.

Original comment by jonathan.skeet on 21 Mar 2013 at 2:50
@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 15, 2015

Original comment by jonathan.skeet on 21 Mar 2013 at 2:50

  • Changed state: Fixed

GoogleCodeExporter commented Mar 15, 2015

Original comment by jonathan.skeet on 21 Mar 2013 at 2:50

  • Changed state: Fixed
@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 15, 2015

Original comment by malcolm.rowe on 6 Apr 2013 at 9:27

  • Added labels: Milestone-1.1.0
  • Removed labels: Milestone-1.1-consider

GoogleCodeExporter commented Mar 15, 2015

Original comment by malcolm.rowe on 6 Apr 2013 at 9:27

  • Added labels: Milestone-1.1.0
  • Removed labels: Milestone-1.1-consider

@malcolmr malcolmr added the enhancement label Mar 15, 2015

@malcolmr malcolmr modified the milestone: 1.1.0 Mar 15, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment