- tz - lists.iana.org

Posix time zone question
by Donald MacQueen Jan. 17, 2012

Jan. 17, 2012

Hi all, I am adding time zone support to our multi-platform application and there are still a few things I cannot figure out. 1) What is the difference between America/Detroit and posix/America/Detroit? The test cases I have written return what looks like the same DST record for a given date no matter which one I use. Under what circumstances would I use posix/America/Detroit? 2) Where is the format of the tz source filesdescribed? Specifically what do SAVE and Letter/S mean below? I am also interested in what the Link format is. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Nic 1979 1980 - Mar Sun>=16 0:00 1:00 D Rule Nic 1979 1980 - Jun Mon>=23 0:00 0 S 3) AIX machines use their own wacky format such at TZ=EST5EDT. Is there any decent mapping to real names? I have googled my brains out on this and searched the comp.time.tz archives on gmane with no luck. Thanks in advance, Donald

13 16

Tokelau crossing date line
by Gwillim Law Jan. 17, 2012

Jan. 17, 2012

A correspondent informed me that Tokelau, like Samoa, will be skipping December 31 this year, thereby changing its time zone from UTC-10 to UTC+14. When I tried to verify this statement, I found a confirming article in Time magazine online (http://www.time.com/time/world/article/0,8599,2103243,00.html) The Wikipedia article on Tokelau also mentions the change. To the best of my knowledge, this hasn't been reported to the tz list yet. Yours, Gwillim Law

5 5

Timezone abbreviations
by Alain Petit Jan. 5, 2012

Jan. 5, 2012

[As I was using an incorrect email, I am resending. Apologies if duplicates were issued] Hi I am looking at the following timezone definition # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/Metlakatla 15:13:42 - LMT 1867 Oct 18 -8:46:18 - LMT 1900 Aug 20 12:00 -8:00 - PST 1942 -8:00 US P%sT 1946 -8:00 - PST 1969 -8:00 US P%sT 1983 Oct 30 2:00 -8:00 US MeST I am trying to make sense of the MeST [the format]. I think PST means "Pacific Standard Time", and P%sT becomes PST or PDT according to the US rule in effect [and making it Pacific Standard Time or Pacific Daylight Time]. However I cannot figure out what MeST would be, apart from Metlakatla Standard Time ? [I found MEST - Middle European Standard Time, but Metlakatla is not in Europe] Searching for Metlakatla [google] always refers it as AKST [Alaska Standard Time]. So 2 questions a) What would MeST mean? [and why no '%s' for it?] b) Where can I find the meaning of these abbreviations [as I will probably find others that will confuse me in the future] Thanks -Alain

2 1

A leap second after next June
by Denis Excoffier Jan. 5, 2012

Jan. 5, 2012

Hi, Just received from IERS: ------------------------------------------------------------------------------ INTERNATIONAL EARTH ROTATION AND REFERENCE SYSTEMS SERVICE (IERS) SERVICE INTERNATIONAL DE LA ROTATION TERRESTRE ET DES SYSTEMES DE REFERENCE SERVICE DE LA ROTATION TERRESTRE OBSERVATOIRE DE PARIS 61, Av. de l'Observatoire 75014 PARIS (France) Tel. : 33 (0) 1 40 51 22 26 FAX : 33 (0) 1 40 51 22 91 e-mail : services.iers(a)obspm.fr http://hpiers.obspm.fr/eop-pc Paris, 5 January 2012 Bulletin C 43 To authorities responsible for the measurement and distribution of time UTC TIME STEP on the 1st of July 2012 A positive leap second will be introduced at the end of June 2012. The sequence of dates of the UTC second markers will be: 2012 June 30, 23h 59m 59s 2012 June 30, 23h 59m 60s 2012 July 1, 0h 0m 0s The difference between UTC and the International Atomic Time TAI is: from 2009 January 1, 0h UTC, to 2012 July 1 0h UTC : UTC-TAI = - 34s from 2012 July 1, 0h UTC, until further notice : UTC-TAI = - 35s Leap seconds can be introduced in UTC at the end of the months of December or June, depending on the evolution of UT1-TAI. Bulletin C is mailed every six months, either to announce a time step in UTC or to confirm that there will be no time step at the next possible date. Daniel GAMBIS Head Earth Orientation Center of IERS Observatoire de Paris, France

1 0

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