- tz - lists.iana.org

Time Zone database change
by Joe Canner Aug. 31, 2008

Aug. 31, 2008

FYI and FWIW: Morocco has decided to switch from DST to standard time (=GMT) on September 1, 2008 instead of September 28, 2008. Regards, Joseph K. Canner IT Director George Washington Academy Casablanca, MOROCCO

1 0

Brazil's dates announced
by Steffen Thorsen Aug. 29, 2008

Aug. 29, 2008

As announced by the government and many newspapers in Brazil late yesterday, Brazil will start DST on 2008-10-19 (need to change rule) and it will end on 2009-02-15 (current rule for Brazil is fine). Based on past years experience with the elections, there was a good chance that the start was postponed to November, but it did not happen this year. It has not yet been posted to http://pcdsh01.on.br/DecHV.html An official page about it: http://www.mme.gov.br/site/news/detail.do?newsId=16722 Note that this link does not always work directly, but must be accessed by going to http://www.mme.gov.br/ first One example link that works directly: http://jornale.com.br/index.php?option=com_content&task=view&id=13530&Itemi… (Portuguese) We have a written a short article about it as well: http://www.timeanddate.com/news/time/brazil-dst-2008-2009.html Regards, Steffen Thorsen - timeanddate.com

1 0

Gaza Strip ended DST while West Bank will end DST at midnight Aug 31, 2008.
by Alexander Krivenyshev Aug. 28, 2008

Aug. 28, 2008

Here is an article, that Mideast running on different clocks at Ramadan. Gaza Strip (as Egypt) ended DST at midnight Thursday (Aug 28, 2008), while the West Bank will end Daylight Saving Time at midnight Sunday (Aug 31, 2008). http://www.guardian.co.uk/world/feedarticle/7759001 http://www.abcnews.go.com/International/wireStory?id=5676087 or http://www.worldtimezone.com/dst_news/dst_news_gazastrip01.html Regards, Alexander Krivenyshev, http://www.worldtimezone.com/dst_news/ New York, NY

1 0

Pakistan DST extended till Oct 31
by Alexander Krivenyshev Aug. 28, 2008

Aug. 28, 2008

Pakistan government has decided to keep the watches one-hour advanced for another 2 months- plan to return to Standard Time on October 31 instead of August 31. http://www.worldtimezone.com/dst_news/dst_news_pakistan02.html OR http://dailymailnews.com/200808/28/news/dmbrn03.html Regards, Alexander Krivenyshev, http://www.worldtimezone.com/dst_news/ New York, NY

1 0

Morocco ends DST early
by Steffen Thorsen Aug. 27, 2008

Aug. 27, 2008

Morocco will change the clocks back on the midnight between August 31 and September 1. They originally planned to observe DST to near the end of September: One article about it (in French): http://www.menara.ma/fr/Actualites/Maroc/Societe/ci.retour_a_l_heure_gmt_a_… We have some further details posted here: http://www.timeanddate.com/news/time/morocco-ends-dst-early-2008.html Best regards, Steffen Thorsen - timeanddate.com

1 0

Australian DST abbreviations causing business problems - still
by Mick Johnston Aug. 26, 2008

Aug. 26, 2008

It's well past time the Australian 'Daylight Saving Time' abbreviations were updated to reflect the current terms and usage. Comments posted previously in the 'australasia' file are outdated and wrong and have been causing lots of problems for years. You don't have to take my word for this. Although most of the URLs identified in the file are not official sites and Daylight Saving Time is legislated by state governments, the exemplary abbreviations are displayed at the Australian federal government website at <http://www.australia.gov.au/Time#daylightsaving> as at 26/8/08. Here is the important bit: Quote: Where daylight saving is being observed: * AEST becomes Australian Eastern Daylight Time (AEDT), and clocks are advanced to UTC +11. * ACST becomes Australian Central Daylight Time (ACDT), and clocks are advanced to UTC +10 ½. * AWST becomes Australian Western Daylight Time (AWDT), and clocks are advanced to UTC +9. " Unquote: The abbreviations AEDT, ACDT and AWDT are commonly shortened to EDT, CDT and WDT. Is there really a problem? Yes. I work for a national retail company that makes deliveries across the country. Here is just one example of the sorts of problems we face. Queensland don't have Daylight Saving Time. New South Wales (across the border from Queensland) do have Daylight Saving Time. Due to the fact that the Olsen data uses EST for both 'Eastern Summer Time' (New South Wales) and 'Eastern Standard Time' (Queensland), a delivery from New South Wales to Queensland can have a pickup time of 10.30am EST and a delivery time of 10.00am EST. We like to be efficient but we're not that good. System users only see the EST and get horribly confused. If the problem impacts businesses, then why don't they use their own time zone tables? It's not that simple. It's quite common today to find systems (like ours) that are purchased on an enterprise licence basis from a large international company. It could be difficult to get the company to change the base software product. Also, it's common for software products to run on standard operating systems such as the AIX flavour of Unix, and for the software products to use whatever time zone information is applied by the operating system. Try getting the operating system vendor to change their software and they'll simply tell you it's based on the Olsen updates. Then why hasn't the table been changed already? To answer this question, I need to address some of the comments previously made in the 'australasia' file. The first comment on this subject in the file was made by John Mackin back in 1991: JM:" We in Australia have _never_ referred to DST as `daylight' time. It is called `summer' time." MJ: This comment is more than 17 years old and horribly outdated. I have lived in Australia all my life and have been supporting systems here since well before 1991. Most Australians simply use the term 'Daylight Saving Time'. It's uncommon outside the business environment to use any other term. In business and government, Australians recognized the problems associated with ambiguous abbreviations a long time ago and have generally adopted the 'EDT' form. Various federal government websites (although not official), in an attempt to encourage uniformity, have been displaying the newer abbreviations for some time. See <http://www.bom.gov.au/climate/averages/tables/daysavtm.shtml> <http://www.australia.gov.au/Time#daylightsaving> Paul Eggert wrote an interesting post in 2001 that needs to be addressed. PE: "My own impression is that both "Daylight Time" and "Summer Time" are common and are widely understood, but that "Summer Time" is more popular;" MJ: Based on my day-to-day observations and discussions with people across states, most Australians now don't use the term 'Eastern Summer Time'. PE: "I just used AltaVista advanced search and got the following count of page hits: 1,103 "Eastern Summer Time" AND domain:au 971 "Australian Eastern Summer Time" AND domain:au 613 "Eastern Daylight Time" AND domain:au 127 "Australian Eastern Daylight Time" AND domain:au" MJ: I just googled (26/8/08) similar searches based on an "Australia only" search and my results were: 30,500 - "eastern daylight time" 5,640 - "eastern summer time" PE: "For abbreviations, tools like AltaVista are less useful because of ambiguity. Many hits are not really time zones, unfortunately, and many hits denote US time zones and not Australian ones. But here are the hit counts anyway: 161,304 "EST" and domain:au 25,156 "EDT" and domain:au" MJ: I agree with your comments, which means the figures are totally inaccurate. File Changes: Due to the fact that the file forms part of the JTZU (Java Time Zone Updates) provided by the operating system vendor, I am unable to create and test proposed changes. Also, there are quite a few changes required and I don't want to spend hours making these changes if they're not going to be applied. I ask for your advice on how to proceed with this. I am happy to work with you to produce a complete set of revised rules if you decide to go ahead with this proposal. We will need to change Aus, AW, AS, AT, AV and AN rules and their corresponding zone formats to use the 'E%sT' format. Thanks for your time and assistance Mick Johnston Dept: CGL - IT ES Supply Chain * L4 Bourke St. Melbourne (ILS Support) * (03) 9635 4457 This email and any attachments may contain privileged and confidential information and are intended for the named addressee only. If you have received this e-mail in error, please notify the sender and delete this e-mail immediately. Any confidentiality, privilege or copyright is not waived or lost because this e-mail has been sent to you in error. It is your responsibility to check this e-mail and any attachments for viruses. No warranty is made that this material is free from computer virus or any other defect or error. Any loss/damage incurred by using this material is not the sender's responsibility. The sender's entire liability will be limited to resupplying the material.

1 0

More details about Turkeys DST proposal
by Sue Williams Aug. 20, 2008

Aug. 20, 2008

This article says that around the end of March 2011, Turkey wants to adjust the clocks forward by 1/2 hour and stay that way permanently. The article indicates that this is a change in timezone offset in addition to stopping observance of DST. This proposal has not yet been approved. Read more here... Turkey to abandon daylight saving time in 2011 http://www.turkishdailynews.com.tr/article.php?enewsid=112989 ... Sue Williams

1 0

Re: zdump
by Dan Cotruta Aug. 12, 2008

Aug. 12, 2008

Dear Olson, Many thanks for your quick reply. I did go through the archives a little more carefully after sending my question. As I'm not a C programmer - can you just confirm my understanding of the problem? time_t is part of a standard C library; on 64 bit systems it is defined as being 64 bits long, giving a very large range for the years that can be displayed. int is the standard builtin integer type, which for reasons that evade me is still defined as 32 bits long. the tzcode does some fancy calculations to work out historical/future times of some kind - and obviously trying to fit a 64 bit value into a 32 bit space doesn't work. I hope that's right so far... So then: Why does Madagascar fail? [dcotruta@linnoc ~]$ /usr/sbin/zdump -v -c 2008 Mauritius Mauritius -9223372036854775808 = NULL Mauritius -9223372036854689408 = NULL Mauritius 9223372036854689407 = NULL Mauritius 9223372036854775807 = NULL Here, the limit should be 2008 - therefore the 32 bit limit should not be a problem. Am I missing something? I don't know anything about C programming - is this something that's likely to be fixed at some point soon? I've started work on a Python version of zdump to get around this limitation - is this something that might be useful to the community? If so, I'd appreciate some help decrypting the logic of the tzdata files. Thanks again for your swift reply, Dan On Mon, Aug 11, 2008 at 2:07 PM, Olson, Arthur David (NIH/NCI) [E] < olsona(a)dc37a.nci.nih.gov> wrote: > The numerical values are "number of seconds since midnight, January 1, > 1970; they can be the immense values below on systems where time_t values > are 64-bit entities. > On such systems, extremely large and extremely small time stamps are > associated with years that can't be represented in 32-bit integers, so we > can't correctly convert them to "struct tm"s that represent them--that's why > the NULLs pop out for these very small and very large values. > > From: Dan Cotruta [mailto:dancotruta@linnoc.net] > Sent: Monday, August 11, 2008 8:30 > To: tz(a)lecserver.nci.nih.gov > Subject: zdump > > Someone, please enlighten me - what do the numerical numbers in the output > of zdump stand for? > > What I mean is, for this output: > > [dcotruta@linnoc ~]$ /usr/sbin/zdump -v -c 2008,2009 America/Los_Angeles > America/Los_Angeles -9223372036854775808 = NULL <------ What does this > line signify? > America/Los_Angeles -9223372036854689408 = NULL <------ What does this > line signify? > America/Los_Angeles Sun Mar 9 09:59:59 2008 UTC = Sun Mar 9 01:59:59 > 2008 PST isdst=0 gmtoff=-28800 > America/Los_Angeles Sun Mar 9 10:00:00 2008 UTC = Sun Mar 9 03:00:00 > 2008 PDT isdst=1 gmtoff=-25200 > America/Los_Angeles Sun Nov 2 08:59:59 2008 UTC = Sun Nov 2 01:59:59 > 2008 PDT isdst=1 gmtoff=-25200 > America/Los_Angeles Sun Nov 2 09:00:00 2008 UTC = Sun Nov 2 01:00:00 > 2008 PST isdst=0 gmtoff=-28800 > America/Los_Angeles 9223372036854689407 = NULL <------ What does this line > signify? > America/Los_Angeles 9223372036854775807 = NULL <------ What does this line > signify? > > The number is far too large to be a standard timestamp, even in > milliseconds... so what is it? > > Many thanks, > -- > Dan Cotruta > Operations Manager, London Innovation Centre. > > Tel: 0203 006 7278 > Mob: 0779 163 4020 > > London Innovation Centre, Lombard House, 2 Purley Way, Croydon CR0 3JP > (T) 0845 262 8545 (F) 020 8481 0460 (e) info(a)linnoc.net (w) www.linnoc.net > London Innovation Centre is a trading name of Kingston Innovation Centre > (Properties) Limited. > Registered in England under no. 4557707. > -- Dan Cotruta Operations Manager, London Innovation Centre. Tel: 0203 006 7278 Mob: 0779 163 4020 London Innovation Centre, Lombard House, 2 Purley Way, Croydon CR0 3JP (T) 0845 262 8545 (F) 020 8481 0460 (e) info(a)linnoc.net (w) www.linnoc.net London Innovation Centre is a trading name of Kingston Innovation Centre (Properties) Limited. Registered in England under no. 4557707.

1 3

Turkey to implement 12-month daylight savings in 2 yrs
by Sue Williams Aug. 11, 2008

Aug. 11, 2008

I spotted this news article about a potential change in Turkey. http://www.hurriyet.com.tr/english/domestic/9626174.asp?scr=1 ... Sue Williams

1 0

zdump
by Dan Cotruta Aug. 11, 2008

Aug. 11, 2008

Someone, please enlighten me - what do the numerical numbers in the output of zdump stand for? What I mean is, for this output: [dcotruta@linnoc ~]$ /usr/sbin/zdump -v -c 2008,2009 America/Los_Angeles America/Los_Angeles -9223372036854775808 = NULL <------ What does this line signify? America/Los_Angeles -9223372036854689408 = NULL <------ What does this line signify? America/Los_Angeles Sun Mar 9 09:59:59 2008 UTC = Sun Mar 9 01:59:59 2008 PST isdst=0 gmtoff=-28800 America/Los_Angeles Sun Mar 9 10:00:00 2008 UTC = Sun Mar 9 03:00:00 2008 PDT isdst=1 gmtoff=-25200 America/Los_Angeles Sun Nov 2 08:59:59 2008 UTC = Sun Nov 2 01:59:59 2008 PDT isdst=1 gmtoff=-25200 America/Los_Angeles Sun Nov 2 09:00:00 2008 UTC = Sun Nov 2 01:00:00 2008 PST isdst=0 gmtoff=-28800 America/Los_Angeles 9223372036854689407 = NULL <------ What does this line signify? America/Los_Angeles 9223372036854775807 = NULL <------ What does this line signify? The number is far too large to be a standard timestamp, even in milliseconds... so what is it? Many thanks, -- Dan Cotruta Operations Manager, London Innovation Centre. Tel: 0203 006 7278 Mob: 0779 163 4020 London Innovation Centre, Lombard House, 2 Purley Way, Croydon CR0 3JP (T) 0845 262 8545 (F) 020 8481 0460 (e) info(a)linnoc.net (w) www.linnoc.net London Innovation Centre is a trading name of Kingston Innovation Centre (Properties) Limited. Registered in England under no. 4557707.

1 0