FW: Questions about tzdata implementations
I'm forwarding this message from Chad Eberle, who is not on the time zone mailing list. Those of you who are on the list, please direct replies appropriately. --ado -----Original Message----- From: Chad Eberle [mailto:ceberle@co.pierce.wa.us] Sent: Monday, March 29, 2010 1:15 To: tz@lecserver.nci.nih.gov Subject: Questions about tzdata implementations I apologize if this isn't the right place for this question, but would appreciate any help with tracking down the answer to these questions. Background: We have Java web services that send back date/time values with GMT offsets adjusted for DST following historical rules that match what I see in the northamerica file for America/Los_Angeles. Our client code is largely JavaScript, and depending on the operating system, will sometimes be incongruous about when DST starts or ends (dates before 2007 on Windows and before 1950. As one can imagine, this has caused a few problems. I can't seem to find any solution for the JavaScript end, so I was planning on writing one myself (if anyone knows of a solution, I'd appreciate any pointers). My questions: 1) Is there some reference implementation for the algorithm that selects the correct rule for a given date? 2) For the general US rules, there is a rule that says DST started in 1945 on Aug 14 at 23:00; however, my tests in Java indicate that DST was observed from Feb 9 1942 through Sep 30 1945, continuously. The latter matches the historical information I've found. Is this rule superfluous? Again, any tips would be appreciated. --Chad Eberle
For the general US rules, there is a rule that says DST started in 1945 on Aug 14 at 23:00; however, my tests in Java indicate that DST was observed from Feb 9 1942 through Sep 30 1945, continuously. The latter matches the historical information I've found. Is this rule superfluous?
The U.S. was indeed turning the clock forward one hour continuously from 1942-02 through 1945-09. Before 1945-08-14 this was called "War" time; after it was called "Peace" time. The only affect of the 1942 rule in the "northamerica" file is to change the abbreviations being used. --ado
Hi Chad, All, Whilst I don't have a full Javascript library that could help you here I have compiled the tz database in to a number of common formats (including Javascript/JSON) and created an open source project over at Google Code [1] where you can download the data for any library you intend to create.
From there I would expect that the JSON dataset would be of interest. To select the appropriate timezone rule you would perform the following steps (in pseudo-code):
1. Obtain the UTC timestamp (ref_time) for the reference time you intend to work with. 2. Obtain and include the necessary tzdata js file (file) according to the TZ Identifier requested (e.g. 'Pacific/Pago_Pago' will translate to the tzdata file '/tzdata/js/Pacific/Pago_Pago.js'). 3. For each rule in file: if (ref_time > rule[from]) AND (ref_time <= rule[to]) then return rule. 4. Apply rule[offset] provided in rule to ref_time. Let me know if you have any feedback or further questions on the data provided. If you do create a Javascript library from the data at [1] I hope you will consider making it open source so the community at large can benefit from your hard work. Hope this helps and good luck :-) [1] http://code.google.com/p/tzdata/ Richard Tibbett WorldTimeEngine.com <http://worldtimeengine.com> On Mon, Mar 29, 2010 at 8:15 PM, Olson, Arthur David (NIH/NCI) [E] < olsona@dc37a.nci.nih.gov> wrote:
I'm forwarding this message from Chad Eberle, who is not on the time zone mailing list. Those of you who are on the list, please direct replies appropriately.
--ado
-----Original Message----- From: Chad Eberle [mailto:ceberle@co.pierce.wa.us] Sent: Monday, March 29, 2010 1:15 To: tz@lecserver.nci.nih.gov Subject: Questions about tzdata implementations
I apologize if this isn't the right place for this question, but would appreciate any help with tracking down the answer to these questions.
Background: We have Java web services that send back date/time values with GMT offsets adjusted for DST following historical rules that match what I see in the northamerica file for America/Los_Angeles. Our client code is largely JavaScript, and depending on the operating system, will sometimes be incongruous about when DST starts or ends (dates before 2007 on Windows and before 1950. As one can imagine, this has caused a few problems.
I can't seem to find any solution for the JavaScript end, so I was planning on writing one myself (if anyone knows of a solution, I'd appreciate any pointers).
My questions:
1) Is there some reference implementation for the algorithm that selects the correct rule for a given date?
2) For the general US rules, there is a rule that says DST started in 1945 on Aug 14 at 23:00; however, my tests in Java indicate that DST was observed from Feb 9 1942 through Sep 30 1945, continuously. The latter matches the historical information I've found. Is this rule superfluous?
Again, any tips would be appreciated.
--Chad Eberle
Actually, step 3 should be: 3. For each rule in file: if (ref_time >= rule[from]) AND (ref_time < rule[to]) then return rule. On Thu, Apr 1, 2010 at 4:32 PM, Richard Tibbett | World Time Engine < richard@worldtimeengine.com> wrote:
Hi Chad, All,
Whilst I don't have a full Javascript library that could help you here I have compiled the tz database in to a number of common formats (including Javascript/JSON) and created an open source project over at Google Code [1] where you can download the data for any library you intend to create.
From there I would expect that the JSON dataset would be of interest. To select the appropriate timezone rule you would perform the following steps (in pseudo-code):
1. Obtain the UTC timestamp (ref_time) for the reference time you intend to work with. 2. Obtain and include the necessary tzdata js file (file) according to the TZ Identifier requested (e.g. 'Pacific/Pago_Pago' will translate to the tzdata file '/tzdata/js/Pacific/Pago_Pago.js'). 3. For each rule in file: if (ref_time > rule[from]) AND (ref_time <= rule[to]) then return rule. 4. Apply rule[offset] provided in rule to ref_time.
Let me know if you have any feedback or further questions on the data provided.
If you do create a Javascript library from the data at [1] I hope you will consider making it open source so the community at large can benefit from your hard work.
Hope this helps and good luck :-)
[1] http://code.google.com/p/tzdata/
Richard Tibbett WorldTimeEngine.com <http://worldtimeengine.com>
On Mon, Mar 29, 2010 at 8:15 PM, Olson, Arthur David (NIH/NCI) [E] < olsona@dc37a.nci.nih.gov> wrote:
I'm forwarding this message from Chad Eberle, who is not on the time zone mailing list. Those of you who are on the list, please direct replies appropriately.
--ado
-----Original Message----- From: Chad Eberle [mailto:ceberle@co.pierce.wa.us] Sent: Monday, March 29, 2010 1:15 To: tz@lecserver.nci.nih.gov Subject: Questions about tzdata implementations
I apologize if this isn't the right place for this question, but would appreciate any help with tracking down the answer to these questions.
Background: We have Java web services that send back date/time values with GMT offsets adjusted for DST following historical rules that match what I see in the northamerica file for America/Los_Angeles. Our client code is largely JavaScript, and depending on the operating system, will sometimes be incongruous about when DST starts or ends (dates before 2007 on Windows and before 1950. As one can imagine, this has caused a few problems.
I can't seem to find any solution for the JavaScript end, so I was planning on writing one myself (if anyone knows of a solution, I'd appreciate any pointers).
My questions:
1) Is there some reference implementation for the algorithm that selects the correct rule for a given date?
2) For the general US rules, there is a rule that says DST started in 1945 on Aug 14 at 23:00; however, my tests in Java indicate that DST was observed from Feb 9 1942 through Sep 30 1945, continuously. The latter matches the historical information I've found. Is this rule superfluous?
Again, any tips would be appreciated.
--Chad Eberle
participants (2)
-
Olson, Arthur David (NIH/NCI) [E] -
Richard Tibbett | World Time Engine