- tz - lists.iana.org

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