Add date timezone (z, Z, O, x, X) support #202
Timezone rules vs. zones
Olson database has two definitions: rules and zones. Rules represent transitions between standard and daylight saving time (or other stuff like war time, or peace time). Zones represent transitions between rules, eg.
Formatting vs. Native Date Object
Date object has a method called
Sidenote: User envorinment's timezone (not date's timezone) name can be obtained on Chrome using
Some libraries (eg. Dojo) use the timezone string excerpt provided by
Some libraries (eg. jsTimezoneDetect) use the same string above plus the timezone offset to better guess its identification. Although, it's still not sufficient, eg.
It's possible to overcome the previous issue by also analyzing the tuple (abbreviated timezone, offset) in different periods of time. But, the analysis requires different attempts depending of the case. Follow an example to illustrate. Let's consider the following excerpt of the BRT (-3:00) timezone from Olson database for this example:
$ TZ=:/usr/share/zoneinfo/America/Maceio node > new Date(2003,0,1) Wed Jan 01 2003 00:00:00 GMT-0300 (BRT) > new Date(2002,0,1) Tue Jan 01 2002 00:00:00 GMT-0200 (BRT) > new Date(2001,0,1) Mon Jan 01 2001 00:00:00 GMT-0300 (BRT) > new Date(2000,0,1) Sat Jan 01 2000 00:00:00 GMT-0200 (BRT) $ TZ=:/usr/share/zoneinfo/America/Bahia node > new Date(2003,0,1) Wed Jan 01 2003 00:00:00 GMT-0200 (BRT) > new Date(2002,0,1) Tue Jan 01 2002 00:00:00 GMT-0200 (BRT) > new Date(2001,0,1) Mon Jan 01 2001 00:00:00 GMT-0200 (BRT) > new Date(2000,0,1) Sat Jan 01 2000 00:00:00 GMT-0200 (BRT)
One last challenge relates to cross-compatibility of
Formatting vs. Extended Olson-timezone-supported Date Object
Parsing vs. Native Date Object
It's not possible to set a timezone on a native Date object other than the automatically set timezone from user/browser environment. So, it turns out that the only goal parsing date timezones into a native Date instance is: to normalize the date according to the parsed timezone.
Parsing vs. Extended Olson-timezone-supported Date Object
Considering we can rely on top of an extended Date object that fully supports Olson timezone, it doesn't make sense to change date according to parsed timezone (as done above). But, the goal here should be to properly set the date instance's timezone the best way possible.
For difficulties similar to the ones presented above on "Format vs. Native Date Object", it won't be possible to precisely parse some timezone strings into it's corresponding zone.
Making long story short: right now, I think the best approach for Globalize is NOT to try to overcome the issues. But, have two modules: (a) the normal date module, which will provide a simple support for date timezone format/parse (skipping some patterns), and (b) enhanced date timezone module, which will rely on a third-party library that supports Olson timezones, and therefore support all CLDR timezone patterns.
I want to bring in the talk I'm having with @ichernev about the basic timezone support (
This is about defining the behavior of the basic timezone formatting and parsing.
Our conception so far of the basic timezone parsing support is to convert the given date input (String) into a native date object by normalizing the given timezone. For example,
The thing is, user loses trace of the original timezone offset. But, @ichernev says it should be preserved in his view (and considering what moment.js users have asked him in the past).
Our conception so far of the basic timezone formatting support is to allow Z, O, x, X patterns only (the numeric ones), and to use the object's
The thing is, this approach doesn't allow formatting any time with a zone offset other than the user's environment one.
@ichernev says that moment.js users have asked him in the past the ability to do so, even if its not DST aware.
The question is: how this should happen?
Extended Olson-timezone-supported Date Object should implement:
Globalize will set
Using this "simple" scheme, we're able to attend everyone in a more flexible way. I mean, we could roll back into the idea of having one only date module, which will attend all worlds: (a) users not caring about timezone, which can use native Date, ie. do nothing (b) users caring about setting arbitrary time offsets, but not caring about named (DST aware) Olson zones, which can use a partially extended Date (c) users really caring about Olson zones, which can use the extended Date with Olson support.
@ichernev, I see moment-cldr as a
A few notes.
I like the proposed solution. We can include a b) level implementation for Date, that just stores the set offset, but actually adjusts the time (so you basically get a Date + an offset).
Excellent question and I agree with you that it's stupid to hard code that information into the source code.
My idea is to deduce that from the CLDR data (note that zone names are kept in a separate file