- tz - lists.iana.org

Incorrect link in europe file
by Rob Crowther Jan. 4, 2012

Jan. 4, 2012

On line 213 of the europe file of the tzdata2011n.tar.gz archive there is a URL: http://student.cusu.cam.ac.uk/~jsm28/british-time/ This appears to no longer exist, I believe the correct URL is now: http://www.polyomino.org.uk/british-time/ I'm not sure if this is the correct process to report a bug, please let me know. Rob

1 0

DST rule for Samoa
by Samuel Colvin Jan. 4, 2012

Jan. 4, 2012

I'm new, so please ignore this if it's garbage. The most recent comment in the *australasia* file on Samoa from Laupue Raymond Hughes (2011-09-02) gives a link to a Samoan goverment website ( http://www.mcil.gov.ws/mcil_publications.html) and gives the dates of DST switches for September 2011 and April 2012. The actual database is correct for April 2012 but gives no future rule. According to the website " Samoa will be one hour ahead of NZ (+12Hrs, in Daylight Saving +13Hrs) " this is consistent with the 2012 date given on the website: *Year**End**Time**Start**Time*2011- - -- - -24 September3:00am to 4:00am 201201 April4:00am to 3:00am- - -- - - (it's wrong for the 2011 date by one day, but that might be because of the weird one day jump at the end of 2011???) I suggest the rule for the future is updated to be similar to New Zealand but changing one hour later. Something like: Rule WS 2012 max - Sep lastSun 3:00s 1:00 D Rule WS 2012 max - Apr Sun>=1 3:00s 0 S Please excuse me if my syntax is wrong. Samuel -- Samuel Colvin S(a)muelColvin.com,

3 2

Summer time during WW2 for Europe/Zagreb
by Miro Dec. 12, 2011

Dec. 12, 2011

Hi, I'd like to ask a question regarding Europe/Zagreb timezone for years 1941-1945. I actually reported a bug in Firefox but that turned out not to be the case. I'll leave url just in case you need more information: https://bugzilla.mozilla.org/show_bug.cgi?id=704486 Anyway, I have Arch Linux installed with latest tzdata package: 2011n. Package information is available at: http://www.archlinux.org/packages/core/x86_64/tzdata. I noticed weird behaviour in Firefox when I try to enter some dates during WW2. Basically summer time doesn't get accounted for. Here is a simple test I ran in Firefox: 8<--------------------------------------------------------- var d = new Date(Date.UTC(1942, 5, 11, 22, 0, 0, 0)); // Firefox 8.0.1, Rhino 1.7 release 3 2011 10 16 d.toString(); // Thu Jun 11 1942 23:00:00 GMT+0100 (CET) // this is what I expect: // Chrome15, IE8, nodejs 0.6.2, and code in Java and Ruby d.toString(); // Fri Jun 12 1942 00:00:00 GMT+0200 (CEST) --------------------------------------------------------->8 I ran the same test on Arch Linux and on Windows 7. On Windows 7 both Firefox and Chrome work as expected. Only Firefox under Linux presents date which doesn't account for summer time. Firefox people told me that Firefox uses native (from glibc probably) tzdata. Therefore, I expected if I use another software that uses latest tzdata (assuming 2011n is latest) I'd get the same result. I used joda-time for that (http://joda-time.sourceforge.net/tz_update.html) But I got correct date. One that does account for summer time. I was wondering If you could point me in a correct direction for trying to fix this bug. Kind regards

6 5

Re: [tz] User time zones
by Steven Abner Dec. 9, 2011

Dec. 9, 2011

Last entry incase someone does use the file. I tried to incorporate Zefram's concept of abbrev-to-candidate. Only a few could be done. I started with CST, PST and realized I would be creating more conflicts, so quickly abandoned zone allocation. The one candidate per time suffices for most of the abbreviations (present or recent events). I removed any references to zones and indicated the time the abbreviation was linked to, either by government or mostly Olson files, since that's what they where/are used for. One stumped me, a few were best guesses as to the times. Multiple candidates per zone was beyond the scope of use, for me, as a date string in my situation can only have one use. There is no way I can query for additional input. Yes UTC should be used if it can be, but I do like my mail referencing my zone abbreviation, so even if a server sent in UTC I would hope my mail converted to my location. Since my project requires that I interpret the abbreviation, I make an attempt at doing so. If you don't use nor find helpful, consider this the rantings of a loon and have your app avoid at all costs. If you can create a better solution please share! I am by no means an expert on time nor its use. There may be one conflict I did create with your database, as mine is different. Please see the Indonesia times and its link to the information it is derived from (in W's), I even think it might contain different offsets?. Thanks again for all replies and here is the corrected version. Steve

1 0

Re: [tz] Adding Asia/Beijing timezone into the database
by Steven Abner Dec. 9, 2011

Dec. 9, 2011

Hi Not taking a position, but one possibility as the user of the database is to install a file or bundle with your application the locale you want. You can easily and a new zone anytime you feel like deviating from the norm. Just make sure to bundle with an installer. Myself, I have patches to the database to create a database. It then gets installed on a system. I also use the patched files and zic so that, if using a different application, it can access the Olson database along with any changes or new information. This doesn't just apply to a database, including compatibly source code has been done for ages. Hope this helpful, just add a patch to backwards file with your new link, or bundle with your app, depending on how you need to use. Steve

1 0

User time zones
by Steven Abner Dec. 9, 2011

Dec. 9, 2011

Thank you for the input! Maybe I should clarify the file. This is an attempt to allow users or peoples access to their times zones. A date string, publication, scanned document, broadcast, etc. can contain the time zone. The tz database even includes these time zones. Some functions even require them to operate. Take the "conceptional problem" example. BRT/BRST are the abbreviations used for the Brazilia Time zone. The ":America/Sao_Paulo" file/location is defined as using the Brazilia Time rule "Brazil". Since this location follows Brazilia Time, it is given the abbreviation for that zone. It is not given a synonym for an offset from UTC. An example to clarify could be the recent offset change of Moscow Time zone from an offset of 3 to that of 4. MSK is the abbreviation for the regional time zone using the standard time definition of that zone. The ":Europe/Moscow" file assigns the offset used for that zone. The Moscow file can now safely be used to represent the "Moskva" rule that is the regional time zone, rather than creating a new zone. Since it is the only location that uses that time zone, one can assign ":Europe/Moscow" file as a link. The GMT example is an oddity case. GMT can stand both for a time, :Etc/GMT which I assume is the observatory location, and the English Isles regional time zone. I am also guessing that that was one of the reasons for UTC, so that an offset of 0 from the observatory would be taken as the offset rather the the time zone the English use. I also only compiled the times, as stated in the file, from 1970 to present. It is known that abbreviations are not unique. However, the list of conflicting zones, see near the end of file, is really small. Especially when Australia is assigned the local, state, country definitions and Indonesia. I will look farther into the assignment to see if any additional zones need creation. As it is clear that a present location might not actually be assigned to a time zone. I did not try to resolve conflicts, just link to the base location file that defined the actual time zone for a region. I did try to make sure to avoid not linking a file that didn't represent the regional time zone, but best to be safe. Thanks again, was helpful! Steve

11 23

Antarctica
by Steven Abner Dec. 8, 2011

Dec. 8, 2011

I was checking that thinggy I created. I came across an oddity. Sooo please verify or invalidate? The Australian government has a web page for their Antarctica division, http://www.antarctica.gov.au/living-and-working/stations/time , which has Casey as 0 hours from AEST/AEDT. The page states modified June 29, 2011. Now translating Australia Time to Olson time of EST/EDT and assuming that the current time they display is that of Casey, with Sydney at a UTC+11(EDT or AEDT) and the database saying UTC+8 for Casey, is this possibly a case of Antarctica being a separate file or does the government have their web page out dated?, or am I mis-interprting things? I didn't check the other stations as I am not sure what is up. This is not an abbreviation question, just so not to link this with what I was discussing earlier. Steve

2 1

Re: [tz] User time zones
by Steven Abner Dec. 8, 2011

Dec. 8, 2011

An addendum, I am not even trying to dictate how the file I submitted be used. I tried to indicate that in the file. One could even use the normal zic output or create one binary file named "Abbr" or "foobar", do a binary search for which file to open from the normal file output of zic. This amounts to two files being read. Again, not trying to limit any possibilities nor suggestions for its use or non-use. This was in response to "required by employer", and I will "force you to do it my way". You may also decide to build structures for more exact ID of a zone origination. This was clearly beyond what was my intent, but super glad it got the thought process going. Steve

1 0

Reply
by Thom Hehl Dec. 8, 2011

Dec. 8, 2011

Can we not fix the emails that come from this list to have the reply to set so all we have to do is hit reply?

4 3

Re: [tz] User time zones
by Steven Abner Dec. 7, 2011

Dec. 7, 2011

LOL, BST stays, only London uses. Last used as actual time zone otherwise was 1983, Bering. Many thanks again for setting me straight! Steve

1 0

User time zones
by Steven Abner Dec. 7, 2011

Dec. 7, 2011

Howdy, I could use some input. I have a different database, lots of reasons for it, which has the attached file as part of the database. I am not an international person, nor is my code yet patented, since the big corps won't take this seriously unless it is. This file was created out of necessity for implementation of operating system functions and a bridge between user and your database, or so I think. Even if you think my thoughts on the intro are invalid, please respond. My initial intent was to submit this for you all to use, but I have already assumed that it will be rejected, the norm! So please, any international users fell free to make suggestive comments. I am in the process of trying to fully automate the list generation, have to hand work some. It has been tested for the strptime(), getdate() and strftime() functions and found not lacking. Of course, this is from test cases I have to think up, since none of the functions I have tested can handle time zones. I am still testing, and re-evaluting for debug-ability and optimizations, so this is not set in concrete. If tz peoples would like to adopt this file, cool! The zic compiler will handle, but your file retrieval will probably need to be altered some. Can't help you there, sorry, different system. There are some notes in the file. In particular this could sate those that aren't fond of the Australia zones and may make Indonesian peoples happy. It addresses, hopefully, French, German and Brazilian peoples too. Off list input also accepted. Steve pheonix(a)zoomtown.com

3 2

Converting from individual cities/states/country names to Windows time zone names
by Daniel White Dec. 6, 2011

Dec. 6, 2011

Hi all, I'm creating a software calculator project, and I'd like my users to be able to convert between time zones using what they're familiar with: country, or city/ state names. So I need to convert from these places to the corresponding Windows time zone, and have been looking for a database online to do so, without success. What I have been able to find is a way to convert from TZID (Olsen) to Windows timezone IDs using this URL: http://unicode.org/repos/cldr-tmp/trunk/diff/supplemental/zone_tzid.html So maybe there's a database which maps all the places of the world to TZID, and then I would use a two-step process instead of one. Any help would be much appreciated. When I say 'database', even just a HTML page would do, and then I can extract the right info.

7 14

Fw: Converting from individual cities/states/country names to Windows time zone names
by yoshito_umaoka＠us.ibm.com Dec. 6, 2011

Dec. 6, 2011

> 4) Out of date data > > You may want to map Belarus to (UTC+02:00) Minsk. However, Minsk > (Belarus) is currently using UTC+03:00/no DST. > Microsoft suggests Windows users in Belarus to use (UTC+03:00) > Kakiningrad for now [http://support.microsoft.com/kb/2625508] > BTW, I found Microsoft has already published the update on November 22 [ http://support.microsoft.com/kb/2633952] For this specific instance, display name "(UTC+02:00) Minsk" was changed to "(UTC+02:00) Nicosia", then display name of "(UTC+03:00) Kaliningrad" was changed to "(UTC+03:00) Kaliningrad, Minsk". -Yoshito

1 0

What license IANA is intending to distribute the timezone database under, BSD or public domain
by Fake name Dec. 4, 2011

Dec. 4, 2011

I hope this forum is the correct place to ask this question. This question is intended for the people at IANA. I work for NetApp, and would like to know what license IANA is intending to distribute the timezone database under, BSD or public domain? BSD is referenced in some of the documentation, but in the past people were assuming this was in the public domain until the lawsuit occurred. Thank you in advance for your answer.

7 6

Re: [tz] Rule ChileAQ in antarctica
by Glenn Eychaner Dec. 3, 2011

Dec. 3, 2011

On Dec 2, 2011, at 9:37 PM, tz-request(a)iana.org wrote: > Zone Antarctica/Palmer is currently defined as - > [...] > The comment mentions that Palmer station keeps the same time as Punta > Arenas, Chile. > > However, Rule Chile in southamerica was updated in 2008a, 2010d, 2011c and > 2011e. The rules for Chile after 1999 are defined as below in the current > version. > [...] > If the comment for Antarctica/Palmer is still true, then I think ChileAQ > in antarctica should be also updated. Does anyone know if ChileAQ in > antarctica was intentionally unchanged or, it's just an error? As far as I (one of the people who proposed the Chile 2010/2011 changes) know, it's an error. (I completely forgot about Chile's Antarctic territiory, and that it would appear in a separate file.) Officially, Chile's Antarctic territory is supposed to follow the same rule as the rest of Chile (according to horaoffical.cl). I don't know if that actually happens in practice, or if the other Antarctic territories have also followed all the shifts in Chile's rules. -G. -- Glenn Eychaner (geychaner(a)lco.cl) Telescope Systems Programmer, Las Campanas Observatory

1 0

Rule ChileAQ in antarctica
by yoshito_umaoka＠us.ibm.com Dec. 2, 2011

Dec. 2, 2011

Zone Antarctica/Palmer is currently defined as - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Antarctica/Palmer 0 - zzz 1965 -4:00 ArgAQ AR%sT 1969 Oct 5 -3:00 ArgAQ AR%sT 1982 May -4:00 ChileAQ CL%sT The comment mentions that Palmer station keeps the same time as Punta Arenas, Chile. # From Ethan Dicks (1996-10-06): # It keeps the same time as Punta Arenas, Chile, because, just like us # and the South Pole, that's the other end of their supply line.... # I verified with someone who was there that since 1980, # Palmer has followed Chile. Prior to that, before the Falklands War, # Palmer used to be supplied from Argentina. The rule ChileAQ in antarctica was copied from southamerica file and the current effective rules are below - Rule ChileAQ 1999 max - Oct Sun>=9 4:00u 1:00 S Rule ChileAQ 2000 max - Mar Sun>=9 3:00u 0 - However, Rule Chile in southamerica was updated in 2008a, 2010d, 2011c and 2011e. The rules for Chile after 1999 are defined as below in the current version. Rule Chile 1999 2010 - Oct Sun>=9 4:00u 1:00 S Rule Chile 2011 only - Aug Sun>=16 4:00u 1:00 S Rule Chile 2012 max - Oct Sun>=9 4:00u 1:00 S Rule Chile 2000 2007 - Mar Sun>=9 3:00u 0 - # N.B.: the end of March 29 in Chile is March 30 in Universal time, # which is used below in specifying the transition. Rule Chile 2008 only - Mar 30 3:00u 0 - Rule Chile 2009 only - Mar Sun>=9 3:00u 0 - Rule Chile 2010 only - Apr Sun>=1 3:00u 0 - Rule Chile 2011 only - May Sun>=2 3:00u 0 - Rule Chile 2012 max - Mar Sun>=9 3:00u 0 - If the comment for Antarctica/Palmer is still true, then I think ChileAQ in antarctica should be also updated. Does anyone know if ChileAQ in antarctica was intentionally unchanged or, it's just an error? Thanks, Yoshito

1 0

America/Creston
by Chris Walton Dec. 2, 2011

Dec. 2, 2011

There are two areas within the Canadian province of British Columbia that do not currently observe daylight saving: a) The Creston Valley (includes the town of Creston and surrounding area) b) The eastern half of the Peace River Regional District (includes the cities of Dawson Creek and Fort St. John) Creston does not have a dedicated zone file; it is assumed that residents of Creston should use "America/Dawson_Creek". This assumption can be inferred from a comment that is currently embedded in the tz database's northamerica file; the comment reads: "Matthews and Vincent (1998) write that Creston is like Dawson Creek.". Earlier this year I stumbled across a detailed article about the time keeping history of Creston; it was written by Tammy Hardwick who is the manager of the Creston & District Museum. The article was written in May 2009. http://www.ilovecreston.com/?p=articles&t=spec&ar=260 According to the article, Creston has not changed its clocks since June 1918. i.e. Creston has been stuck on UTC-7 for 93 years. Dawson Creek, on the other hand, changed its clocks as recently as April 1972 (as is correctly reflected in the current tz database). The current tz rules state that a separate zone file should be created for regions that differ after 1970. So... I am proposing the addition of "America/Creston" to the database. Unfortunately the exact date for the time change in June 1918 remains unknown and will be difficult to ascertain. I e-mailed Tammy a few months ago to ask if Sunday June 2 was a reasonable guess. She said it was just as plausible as any other date (in June). She also said that after writing the article she had discovered another time change in 1916; this is the subject of another article which she wrote in October 2010. http://www.creston.museum.bc.ca/index.php?module=comments&uop=view_comment&… Here is a summary of the three clock change events in Creston's history: 1. 1884 or 1885: adoption of Mountain Standard Time (GMT-7) # Exact date unknown 2. Oct 1916: switch to Pacific Standard Time (GMT-8) # Exact date in October unknown; Sunday October 1 is a reasonable guess. 3. June 1918: switch to Pacific Daylight Time (GMT-7) # Exact date in June unknown; Sunday June 2 is a reasonable guess. note#1: On Oct 27/1918 when daylight saving ended in the rest of Canada, Creston did not change its clocks. By not changing the clocks, Creston had effectively transitioned itself back to Mountain Standard Time. note#2: During WWII when the Federal Government legislated a mandatory clock change, Creston did not oblige. Creston was able to claim that it had moved itself back to the Pacific Time Zone and could observe daylight saving (Pacific War Time) without changing the clocks. After the war, Creston conveniently moved itself back to Mountain Standard Time, again with no change to the clocks. note#3: There is no guarantee that Creston will remain on Mountain Standard Time (UTC-7) forever. The subject was debated at least once this year by the town Council. http://www.bclocalnews.com/kootenay_rockies/crestonvalleyadvance/news/11676… Here is a proposed zone entry for the northamerica file: # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/Creston -7:46:04 - LMT 1884 -7:00 - MST 1916 Oct 1 -8:00 - PST 1918 Jun 2 -8:00 1:00 PDT 1918 Oct 27 2:00 -7:00 - MST 1942 Feb 9 2:00 -8:00 Canada P%sT 1945 Sep 30 2:00 -7:00 - MST Alternatively the dates in Oct 1916 and June 1918 could be omitted since we don't know what they are; this would cause zic to default to Oct 1/1916 and June 1/1918. # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/Creston -7:46:04 - LMT 1884 -7:00 - MST 1916 Oct -8:00 - PST 1918 Jun -8:00 1:00 PDT 1918 Oct 27 2:00 -7:00 - MST 1942 Feb 9 2:00 -8:00 Canada P%sT 1945 Sep 30 2:00 -7:00 - MST Note the use of the Canada rule in 1942 results in the use of "PWT(pacific war time)" and "PPT(pacific peace time)". The zone.tab entry should look like this: CA +4906-11631 America/Creston Mountain Standard Time - Creston, British Columbia # # # # # # And now one last tidbit: In the first of Tammy's articles she quotes the Friday November 1/1918 edition of the Creston Review. The quote includes these two statements: 'Sunday the CPR went back to the old system of time...' '... The daylight saving scheme was dropped all over Canada at the same time,' These statements refer to a transition from daylight time to standard time that occurred nationally on Sunday October 27/1918. This transition was also documented in the Saturday October 26/1918 edition of the Toronto Star. The Toronto Star articles reads as follows: 'BACK TO OLD TIME - Canada Returns to Orthodox Measurement of Time To-morrow Morning. Ottawa, Oct. 26.---"Daylight saving" comes to an end Sunday morning, October 27, at 2 o'clock, when Canada returns to the orthodox measurement of time. Either the simple ceremony of stopping the clock for an hour or sliding the hands forward 11 hours should be carried out. To turn the hands back would be to injure its mechanism.' My reason for providing these two references to the October 27/1918 transition, is that the tz database currently defines it as being on Thursday October 31 instead of Sunday November 27. This is an error that presumably needs to be corrected in the rules for "Canada", "Regina", "Vanc", "Winn", and "Edm". -chris

1 1

Fiji DST 2011/12 change (again)
by Ken Rylander Nov. 29, 2011

Nov. 29, 2011

Hi, Another change to the Fiji DST end date. In the TZ database the end date for Fiji DST 2012, is currently Feb 26. This has been changed to Jan 22. >From www.fiji.gov.fj:<http://www.fiji.gov.fj:> Amendments to daylight savings Ministry of Information Oct 17 |13:59 pm The end of daylight saving scheduled initially for the 26th of February 2012 has been brought forward to the 22nd of January 2012. The commencement of daylight saving will remain unchanged and start on the 23rd of October, 2011. An official gazette reflecting this change will be released early this week. -ends- http://www.fiji.gov.fj/index.php?option=com_content&view=article&id=5017:am… Please add to next tz update. Cheers, /Ken ________________________________ Notice of Confidentiality: The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this information is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system.

4 7

Reading binary files
by Thom Hehl Nov. 17, 2011

Nov. 17, 2011

OK, I give up. I've tried looking at the source code and it's hopeless. Can someone please explain to me how to read the binary files and turn it into timezone information? All I need to do is write a function that will take a UTC date and convert it into a timezone with a name that I specify and convert it back again. (I understand there are precision issues with the last one.) The code is not commented and I can find no documents. Please, I beg you, help me.

7 9

U.S. abbreviations in 1942
by Garrett Wollman Nov. 15, 2011

Nov. 15, 2011

The U.S. went on permanent DST for the duration of World War II starting on February 9, 1942. The following quotation from /Broadcasting/ magazine of 1942-02-02 sheds some more light on abbreviations used in the U.S. during the early 1940s: : At present, times for network programs are nationally released in : accordance with their broadcasts on the East Coast and are labelled : EST. In previous years, during the months that daylight saving time : was in effect in certain parts of the country, including New York, : the designation was changed to EDST for that period. : [... T]he MBS publicity department stated that it will follow the : custom of other years and label program times as EDST. NBC said : that [...] Red Netowrk programs would be shown as EST after Feb. 9. : [...] CBS has announced that "concurrent with national daylight : saving beginning Feb. 9, Columbia network's time designation on news : releaess is Eastern Time. This phrase was chosen because the time : is no longer standard and because, with national daylight saving, : EDST seems unessential." -GAWollman

1 0

Barnaby
by Thom Hehl Nov. 9, 2011

Nov. 9, 2011

OK, first pass of http://code.google.com/p/barnaby is available for download of the source. This is a C++ library with two functions: 1) List all of the timezones 2) For a given timezone name, convert UTC to that timezone It will build a DLL for you if you open the project using Visual C++. The timezone data is only version 2011i, so I will need to update it soon. Please let me know any and all feedback. Blessings!

5 7

FW: Barnaby
by Thom Hehl Nov. 8, 2011

Nov. 8, 2011

>You're using zone.tab as a canonical list of timezones, which it isn't. >zone.tab is only useful for selecting timezones via countries; for a >list of all timezones you can serve you should just look at the tzfiles. Did you read the readme? That is the next thing I'm going to fix. >Your usage of time_t is not appropriate. The type you want there is >dictated by the tzfile format, not by libc. The API needs to use time_t, so the usage is dictated by the use case, not by the tzfile, which is why it's appropriate. >You're doing a linear search (in transitionTimesIndex) that should really >be a binary search. Yeah, that can be optimized. The problem with doing a binary search is that you're not looking for an equal condition, but the smallest gap the thing you're looking for fits into. I'm aware that a binary search would improve performance some, but didn't devote time to it yet. Again, this is a beta drop designed to get the job done so I can move on with other priorities that pay money. :) >Overall it looks like you're interpreting (the 32-bit part of) the tzfile >correctly, but I find the code too messy to be sure. >You have some instance methods that should be class methods ("static"). >There is much else that is poor about your object model, but that's all >off topic for this list. Feel free to email me off list as you please for any improvements you might suggest. As I indicated in the read-me there is much room for improvement, but this meets my current needs. Open source is all about refining code over iterations, right? Whatever changes you'd like to suggest will be re-visited when I get some time to come back and work on this more. Thanks for the excellent feedback. -----Original Message----- From: Zefram [mailto:zefram@fysh.org] Sent: Tuesday, November 08, 2011 12:44 PM To: Thom Hehl Cc: tz(a)iana.org Subject: Re: [tz] Barnaby Thom Hehl wrote: >http://code.google.com/p/barnaby You're using zone.tab as a canonical list of timezones, which it isn't. zone.tab is only useful for selecting timezones via countries; for a list of all timezones you can serve you should just look at the tzfiles. Your usage of time_t is not appropriate. The type you want there is dictated by the tzfile format, not by libc. You're doing a linear search (in transitionTimesIndex) that should really be a binary search. Overall it looks like you're interpreting (the 32-bit part of) the tzfile correctly, but I find the code too messy to be sure. You have some instance methods that should be class methods ("static"). There is much else that is poor about your object model, but that's all off topic for this list. -zefram

1 0

Decoding timezone data
by Thom Hehl Nov. 8, 2011

Nov. 8, 2011

OK, so I'm making some progress on my library. I'm attempting to read the timezone information for America/Kentucky/Louisville. When I run through the values for transition times, I get 177 values such as follows: 2661690496, 2693140096, 2759063296, ... The docs say these transition times are in values returned by the c time function, which returns seconds since midnight, 1/1/1970. If that is the case, then the three values above convert to: May 6, 2054 at 2:28:16 PM May 5, 2055 at 2:28:16 PM June 6, 2057 at 2:28:16 PM These are nowhere near the DST conversion dates for these years and are moving forward. This appears incorrect. Can someone show me what I'm doing wrong? Thanks.

5 8

"Standard byte order"
by Thom Hehl Nov. 8, 2011

Nov. 8, 2011

I'm assuming that "Standard byte order" referred to over and over in the docs means Most Significant Byte first? It should really be documented that way. As far as I know, there is no standard byte order.

9 15

Re: [tz] Australian time zone abbreviations
by Shaun Bouckaert Nov. 8, 2011

Nov. 8, 2011

On 6 November 2011 20:51, Eric Ulevik <eulevik(a)gmail.com> wrote: > On Sun, Nov 6, 2011 at 9:20 PM, Shaun Bouckaert > <shaun.bouckaert(a)gmail.com> wrote: > [snip]> http://australia.gov.au/about-australia/our-country/time > [snip]> I believe that the abbreviations used on the federal > government> website should be used. > Time zones in Australia are legislated by acts of state governments, > not the federal government. The acts mostly refer to "summer time" and > "standard time". > > Eg. South Australia: > http://www.austlii.edu.au/au/legis/sa/consol_act/dsa1971165/ > > Regards, > > Eric Ulevik > In the absence of any specific mention in the state legislation of an appropriate abbreviation, and considering the timezones and their abbreviations span multiple states, I see no reason why federal government documentation on the matter shouldn't be recognised, especially considering the only basis for the current system is a couple of AltaVista searches and the opinion of Australian's on the list at the time. Shaun Bouckaert

4 5