- tz - lists.iana.org

Kazakhstan historic time
by Jesper Norgaard Welen Nov. 16, 2008

Nov. 16, 2008

Recently I was checking the timezone map from Eric Muller (Adobe) and came to the conclusion that he had the Kostanai (or Kustanai) area as part of the Qyzylorda time zone although they are not even adjacent, but still on comparatively the same longitude. The area of Kostanai I assumed was part of the main area of Kazakhstan represented by Asia/Almaty. I am not sure where Eric got his information from, but the story doesn't end here. I found a russian astronomical page HYPERLINK "http://zaytsev.com/forum/viewtopic.php?p=10571"http://zaytsev.com/forum/vie wtopic.php?p=10571 that raises the issue that this so-called ZET 8 time is wrong. Here is a translation from Google of the original russian article === Quote begin === Thu Apr 17, 2008 4:14 pm Posted: Thu Apr 17, 2008 4:14 pm ZET Post: Temporary amendments to the ZET ---------------------------------------------------------------------------- ---- Help solve the dilemma with the definition of a temporary correction. I was born in Kostanai area in November 1976. Some astrological programs, including ZET 8, provide a temporary amendment +4 GMT. At the same time, Moscow is +3 GMT. This means that the difference with Moscow entire 1 hour. But it never was. The difference has always been 2 hours. And parents attest to the fact that the difference with Moscow has always been 2 hours. The program ZET 8 geo gives a sharp change of a temporary amendment to a very long period: 01 Jan 0001 00:00 LMT +00:00:00 01 Jan 0001 00:00 LMT +00:00:00 02 May 1924 00:00 +04:00:00 02 May 1924 00:00 +04:00:00 21 Jun 1930 00:00 +05:00:00 21 Jun 1930 00:00 +05:00:00 01 Dec 1956 00:00 +04:00:00 01 Dec 1956 00:00 +04:00:00 01 Apr 1981 00:00 +05:00:00 01 Apr 1981 00:00 +05:00:00 In fact this change temporary amendment in 1956 is due to the change of time zones. I can not find any information about the change of time zones in 1956, although the time change occurred not only in the Kostanai region. This tool, please, if anyone has information about this change of temporary amendments of 1956, which legislation has been done? Even familiar to consultants not able to answer that question. Do not mistake that caused even if Spravochnikov coordinates of the first edition of Cities and temporary amendments and continually reissued by different authors ... Let us find the truth in this matter, as he stubbornly insist that the time of my birth at +1 GMT differs from the time in the program and is +5 GMT. I think if I would have the rights to many "go" horoscopes ... But it is still "a friend of Plato me, but the truth is more expensive ..." === Quote end === I guess you can't expect miracles from an automated translation. What I understand from the email is that this person claims to have been born in Kostanai in 1976 and that time there since has "always" been GMT+5 or rather Moscow time plus 2 hours. This does not correspond to the Asia/Almaty time zone but corresponds pretty well with the Asia/Qyzylorda time zone. The thread is not faultless for instance another person grabs a part of the World Time Explorer file Historic.txt and concludes that Astana was on GMT+5 from 1930 to 1991 while in fact the correct number is GMT+6 I might be exaggerated in assuming this is authoritative information (yet) but all the same perhaps readers of this mailing list have more information they can share. The mixture of Eric's map with the administrative regions however shows another difference that I can't explain, see the following map: HYPERLINK "http://www.worldtimeexplorer.com/Kustanai-2008-11-09.png"http://www.worldti meexplorer.com/Kustanai-2008-11-09.png The red borders are the time zones of his map. The black zones are the recent administrative regions, as we can also see on this wikipedia map of the Kostanai region: HYPERLINK "http://en.wikipedia.org/wiki/Image:Kost_obl.svg"http://en.wikipedia.org/wik i/Image:Kost_obl.svg but Eric's map contains a bite of the Astana area. In conclusion if the Kustanai/Kostanai region has always been on Qyzylorda time, we don't have to do anything to Kazakhstan timezones but it would be good to document this on the notes to the Asia/Qyzylorda time zone. Whether the Kustanai region covers modern-time administrative area or not will then be very important to the maps of Eric and WTE, but not directly to the tz database. Also I think it would be good to add all current administrative regions of Kazakhstan to the notes of the asia file. Any comments are welcome. - Jesper Nørgaard Welen No virus found in this outgoing message. Checked by AVG. Version: 7.5.524 / Virus Database: 270.9.4 - Release Date: 2008-11-14 0:00

1 0

America/Resolute
by Chris Walton Nov. 14, 2008

Nov. 14, 2008

Not that anybody asked... but I thought I would provide an update on America/Resolute. Some of you may remember that in 2006, the small community of Resolute a.k.a. "Resolute Bay" in Canada's arctic stopped the biannual practice of changing the clocks. In March of 2007 I initiated the creation of a new Canadian zone named "America/Resolute" with a fixed time of "UTC-5". The only web reference that I ever came across (other than my own postings) was this: http://www.nnsl.com/frames/newspapers/2006-11/nov13_06none.html Since there has been no recent documentation, legislation, news reports, or any other information on this subject, I decided to place a another call to the Resolute "hamlet office" last week to get an update. I was able to confirm that Resolute is still stuck on UTC-5. Thus the current information in the TZ database remains correct. I will mention, however, that the residents of Resolute believe that they are changing "time zones" twice a year. In winter months, local time is qualified with "Eastern Time" which is really "Eastern Standard Time (UTC-5)". In summer months, local time is qualified with "Central Time" which is really "Central Daylight Time (UTC-5)". I don't think anybody expects the TZ database to accommodate for this... as long as the offset from UTC is correct. I did notice today that the entry for Resolute in the zone.tab says "Eastern Time - Resolute, Nunavut". To be consistent with other Canadian zones that don't observe daylight saving time, it should probably say "Eastern Standard Time - Resolute, Nunavut". -chris -----Original Message----- From: Chris Walton Sent: March 14, 2007 11:03 AM To: 'tz(a)elsie.nci.nih.gov' Subject: RE: proposed tz patches for Cuba, Mongolia, Turkey, Resolute, Indonesia A couple of weeks ago I reported that "Resolute" on Cornwallis Island in Nunavut Canada did not change its clocks on October 29/2006. I only had one source of information. http://www.nnsl.com/frames/newspapers/2006-11/nov13_06none.html Today I phoned the "hamlet office" to find out what Resolute was doing with its clocks. The individual that answered the phone confirmed that the clocks did not move at the end of daylight saving on October 29/2006. He also told me that the clocks did not move this past weekend (March 11/2007). He was not sure whether to refer to the local time as "Eastern Time" or "Central Time" but we did a quick time check comparing his clock vs my clock and I was able to confirm that Resolute is currently running on UTC-5. The implication is that Resolute has been on UTC-5 (Eastern Standard Time or Central Daylight Time) since April 2/2006. I was also told that the hamlet council has not officially announced what will happen next fall. Apparently there was confusion for residents when the time did not change last October... specifically with respect to television schedules. America/Resolute should use the "Canada" Rule up to October 29/2006. After that it should be fixed on Eastern Standard Time until further notice. -chris

1 0

Re: Posix Timezone format
by HJWOUDENBERG＠aol.com Nov. 14, 2008

Nov. 14, 2008

I have developed a time zone systems that uses ISO-3166 AnyDateTime CREATED BOLD DARING NEW TECHNIQUES. The results had amazing results: · Incredible speed. · Incredible capabilities. · Incredible simplicity. The results are exciting, but striving for perfection required tremendous tenacity but was very satisfying. AnyDateTime¾USES INTERNATIONAL STANDARDS. Date/time format conversion. Uses the ISO-8601 (International Organization for Standardization) date/time formats. The Internet XML requires the use of this format. · Converts North America formats 06/18/2008 01pm to the common world use of 18.06.2008 13:00 or the international standard 2008-06-18T13:00:00 · Features that are unique to international ISO-8601 standard are implemented into local date/time formats. Therefore, an international date/time can be converted to a local date/time and back to the international date/time. Date/time time-zone conversion. Uses the ISO-3166 location codes for countries and states. · The same codes used to mail letters are used to converting US EST (EDT) to CST (CDT), MST (MDT), PST (PDT), AST (ADT) or HST or anywhere else in the world. Uses the IATA city codes (International Air Transport Association). · The same 3 letter code on your airline luggage can be used for time zone conversion and currency conversion. Date/time manipulation. Uses the ISO-8601 durations. · The ISO-8601 duration “PnYnMnDTnHnMnS” is used for working with years, months, days, hours, minutes, seconds or fractions of time regardless of MM/DD/YYYY, DD.MM.YYYY or YYYY-MM-DD format. Adding/subtracting date/time Setting date/time to a specific date/time, like the start and ending of daylight. Getting date/time for different formats like “6/18/2008 1pm” or “2008-01-18 13:00” Comparing different formats equal “06/18/2008 6pm-05;00” = “2008-06-19 01:00+02:00” Finding the difference in years, hours, days, hours, minutes, seconds or in combinations of elements. · Created a new “Event Algebra” by expanding the ISO-8601 durations “=±P=±nY=±nM=±nD=±T=±nH=±nM=±nS=±.nF”. The event of the start of daylight saving time is: The 3rd month, the 2cd week, on the 1st day of the week at 2am The formula =03m14d-1dwT=2h This is much simpler than the Microsoft’s Excel or Visual Basic methods. Currency conversion. Global selling requires currency conversion as well as time conversions. The same way is sued for currency conversion as is used for time zone conversion. AnyDateTime UNIQUE CREATIONS. Created the fastest time zone conversion routine in the world. For the first time every, computers can do simultaneous mixed-radix arithmetic. If it is plugged into the C/C++ conversions routines or IBM’s durations routines they run 2.75 time faster. Created the fastest date/time validation routines in the world. The checking for 30 and 31 day months and leap years is so fast it is almost un-measurable for a million date/time checks, so it is always on. Java date/time check is so slow it permits it to be turned off for speed. IBM’s date/time almost doubles the CPU usage if date/time is checked. C/C++ requires programmers to write their own 30 day month check else it converts 2008-06-31 to 2008-07-01 without error indicator. Created “Event Algebra” that simplifies event calculation and provides a standard method for event calculation. The ISO-8601 duration “PnYnMnDTnHnMnS” has been expanded to create “Event Algebra”. Created an Internet auto synchronization for client table update. When North America changed the daylight savings time, your computer was updated automatically over the Internet. However, companies doing business over around the world need the time zones of everywhere in the world. Those nice time zone lines on maps or computer screens are no more than approximations and don’t reflect daylight savings time. The advantages of a local service: · A local service program can do in minutes what takes days using a Web-service. · The auto-synchronization feature give local services the same features as Web-services, it updates the tables on the client computer without any manual intervention. The risks with Web-services: · Some applications kill Internet performance, so all other applications suffers. · The potential for gouging by application service providers (ASP). · No control over ASP performance or quality. The disadvantage of other local services: · Other date/time routines use the “tz.database” that must be compiled on the client’s computer and requires manually intervention to put into production. AnyDateTime date/time data type has incredible capabilities. Herman J Woudenberg The world’s largest date range has a worlds largest date range of 2 million years (±1 million –1 year). UNIX/LINUX JAVA & C/C++ have a date range of 68 years, 1970 to 2038. ANSI COBOL-90 has a date range from 1601 to 9999. IBM Power PC computer has a date range from 1483 to 9999. Microsoft .NET (Vista) has a date range from 0001 to 9999. Microsoft Com (XP) has a date range from 1600 to 9999. Oracle has a date range from 4500BC to 9999 AD. The world’s smallest time precision as small as femto-seconds, 15 fractional digits_[i]_ (aoldb://mail/write/template.htm#_edn1) . UNIX and C only have whole seconds, no fractions of seconds. Java has milliseconds, 3 fractional digits. IBM has up to microseconds, 6 fractions digits. Microsoft has 100 nanoseconds, about 7 fractional digits. Oracle has up to 9 fractions digits. Network Time Protocol has 10 fractional digits. ____________________________________ _[i]_ (aoldb://mail/write/template.htm#_ednref1) Fractions of seconds. Milli-second (ms or msec) is one thousandth of a second (.999 or 10-3). It is used for read/write time of hard disk or CD-ROM and packet travel time on the Internet. Micro-second (us or Greek letter mu plus s) is one millionth (.999_999 or 10-6) of a second. It is used to measure the speed of CPUs. Nano-secnd (ns or nsec) is one billionth (.999_999_999 or 10-9) of a second. It is used for read/write time of random access memory (RAM). Pico-second is one trillionth (.999_999_999_999 or 10-12) of a second, or one millionth of a microsecond. It is used by the Net Work Time Protocol clock. Femto-second is one millionth of a nanosecond (.999_999_999_999_999 or 10-15) of a second. It is used in laser technology. Atto-second is one quintillionth (.999_999_999_999_999_999 or 10-18) of a second. It is a used in photon research. **************Get the Moviefone Toolbar. Showtimes, theaters, movie news & more!(http://pr.atwola.com/promoclk/100000075x1212774565x1200812037/aol?red… p://toolbar.aol.com/moviefone/download.html?ncid=emlcntusdown00000001)

1 0

West Wendover NV time zone
by Jesper Norgaard Welen Nov. 13, 2008

Nov. 13, 2008

Vernon Cole claimed to me that we need a new time zone for West Wendover, Nevada. After checking the case I think he is right. West Wendover lies close to Wendover, Utah, but according to state border application they are on Pacific time while Wendover is on Mountain time. West Wendover seems to have a history long back of using Mountain time for convenience, but that use was never official. The main reason is that every most relations to other geographic locations close-by will be using Mountain time, and the bigger cities on the Nevada region are 100 miles or more from West Wendover. Apparently real problems began in the eighties and nineties when the city council began to insist on using Pacific time officially. In 1999 the DOT approved an application from West Wendover about shifting to Mountain time officially and on a permanent basis, using DST etc. The exact moment of application was opportune, the 31.st. of October 1999 at 2:00 PDT (GMT-7) when most of Nevada went back to PST (GMT-8) then West Wendover just stayed on GMT-7 (Mountain Standard Time). The case of the Nevada northern border (Jackpot, Owyhee, and Mountain City), which is also using Mountain time is different, because they seem to have been using Mountain time "always" so they can use time zone America/Denver. The legislation is resumed here: HYPERLINK "http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=1999_register&doc id=99-27240-filed"http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname= 1999_register&docid=99-27240-filed There is some of the history on the Wikipedia page: HYPERLINK "http://en.wikipedia.org/wiki/West_Wendover"http://en.wikipedia.org/wiki/Wes t_Wendover Jesper Nørgaard Welen Email: jnorgard(a)Prodigy.Net.mx Project Leader (Líder de Proyecto) Software CIMMYT - Centro Internacional de Mejoramiento de Maíz y Trigo Dirección: CIMMYT Int. c/o Jesper Nørgaard Km. 45, Carretera México-Veracruz El Batán Texcoco, Edo. de México CP 56130 MEXICO Tel.: +52 (55) 58-04-20-04 ext. 1374 Fax: +52 (55) 58-04-75-58 Tel. Casa: 53-10-05-95 ó 53-10-97-78 Download the shareware program World Time Explorer, I made: HYPERLINK "http://www.worldtimeexplorer.com/index.html"http://www.worldtimeexplorer.co m/index.html No virus found in this outgoing message. Checked by AVG. Version: 7.5.524 / Virus Database: 270.9.0/1772 - Release Date: 2008-11-06 20:23

2 1

Caracass now GMT-4:30?
by MB Nov. 10, 2008

Nov. 10, 2008

Is the UTC offset for Carass -04:30 in v2008i? I'm using the TZInfo ruby gem which is currently using v2008g and it still lists it as -4:00. http://www.timeanddate.com/worldclock/timezone.html?n=58 thanks

2 1

US Report on DST released
by Steffen Thorsen Nov. 10, 2008

Nov. 10, 2008

The United States’ extended daylight saving schedule, which resulted from the Energy Policy Act of 2005, has saved energy for the nation according to a newly released government report. The energy savings were small compared to the national total electricity consumption. We have a short article about it: http://www.timeanddate.com/news/time/usa-dst-report-energy.html The full report is available here: http://www1.eere.energy.gov/ba/pba/pdfs/epact_sec_110_edst_report_to_congre… Regards, Steffen - timeanddate.com

1 0

tzdata2008i.tar.gz
by Olson, Arthur David (NIH/NCI) [E] Nov. 7, 2008

Nov. 7, 2008

The file... ftp://elsie.nci.nih.gov/pub/tzdata2008i.tar.gz ...is now available; this reflects changes circulated last week on the time zone mailing list to the southamerica and zone.tab files, with Argentina DST rule changes and United States zone reordering and recommenting. --ado

7 6

Bug in Argentina timezone
by Ricardo I. Vieitez Nov. 7, 2008

Nov. 7, 2008

There is a bug in the Argentine timezone, as not the whole country but parts of it are GTM-2 because of summer time. There is more information available (including a patch) at http://bugs.gentoo.org/show_bug.cgi?id=245283 My best regards, -- Ricardo I. Vieitez

1 0

FW: RE: How to determine whether the OS has the latest DST rules
by Olson, Arthur David (NIH/NCI) [E] Nov. 6, 2008

Nov. 6, 2008

I'm forwarding this message from Phil Guera, who sent it by way of a secure mail server. --ado Florence, I did some programming to read this information. Basically, the information is given in the area that Microsoft calls TZI. It's a complicated element to decipher, but if you give me the timezones you are interested in, I can give you screen shots of the interpretation of the registry binary data. I wrote this TimeZonesExplorer just before Microsoft added some historical capability to their registry's handling of timezones, and never did update it to read the historical data, but the way MS stores the info is based on the zone, current year, and subset of yearly historical data. Though their treatment of historical data doesn't go back in time very far like the TZ database does. I'm still running Windows XP pro, but I believe the registry is structured the same on Vista at this time. At any rate with the screen shots, you should be able to see the basics of how to make the binary data more human readable. It's just a matter of splitting the TZI info into parts and performing some hex math conversion to get to the actual information contained within it. Phil Guerra North Kansas City Hospital Information Technology Enterprise Technologies phillip.guerra(a)nkch.org Toll Free Relay Phone: 866-797-5805 AOL IM: Mycroft2800

1 0

FW: Looking for advices regarding tzdata
by Olson, Arthur David (NIH/NCI) [E] Oct. 30, 2008

Oct. 30, 2008

I'm forwarding this message from Dmitri Pal, 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: Dmitri Pal [mailto:dpal@redhat.com] Sent: Friday, October 24, 2008 2:52 To: tz(a)lecserver.nci.nih.gov Subject: Looking for advices regarding tzdata Hi, I am new to tzdata and advanced time zone conversion technics that it offers. I read couple articles about tzdata on wikipedia and in man pages. So far I do not see what I am looking for so may be it just does not exist. Here is what I am trying to accomplish. Input: YYYYMMDDHHMMSS - date or some other date format that can be easily broken into tm structure. TZ information - I was hoping to use some kind of meaningful string so time zone names. Names from zone.dat would work perfectly. Output: Number of seconds since 1 Jan 1970 in UTC time that corresponds to the time stamp Processing: * The function that would do the conversion needs to parse and validate the format before conversion can happen. That includes validating the TZ name. * Would be nice to use standard libc functions to do this conversion as much as possible What is missing: I am currently on Red Hat Enterprise Linux 5.1. It has /usr/share/zoneinfo and there I found zone.dat. Is there any function or set of functions that allow me to interact with this database like: get_next_timezone_name - to iterate through the list and get the timezone. Is there any abstraction around this file? In different distributions it can be in different places and under different names. But libc functions hide this complexity so is there any API that will let me to enumerate timezones and or check if the XXXX/YYYY is the correct valid time zone name without dealing with the file myself? Also the other part is determining the daylight savings at the moment of conversion in the specified time zone? Would it be something like breaking the input I have into the tm structure , calling tzset(timezonename) and then call mktime? #include <time.h> #include <stdlib.h> time_t my_time (struct tm *tm, char *timezonename) { time_t ret; char *tz; tz = getenv("TZ"); setenv("TZ", timezonename, 1); tzset(); ret = mktime(tm); if (tz) setenv("TZ", tz, 1); else unsetenv("TZ"); tzset(); return ret; } This example is based on the timegm example but seems to contradict mktime man page that states that mktime sets the timezone variable itself. In other words I can populate a part of the tm from the data I have but I need to populate the tm_isdst based on the timezone. Would the code above accomplish the task? I feel like something might be wrong with this but I am not sure what. So this is where I am and I am bit lost. Please advise. Thank you Dmitri Pal

1 0