- tz - lists.iana.org

FW: Corrections to australasia zoneinfo
by Olson, Arthur David (NCI) June 19, 2000

June 19, 2000

Nickolas is not on the time zone list; be sure to direct replies appropriately. --ado > -----Original Message----- > From: Jeitner, Nickolas [SMTP:nickolas.jeitner@eds.com] > Sent: Sunday, June 18, 2000 10:34 PM > To: 'tz(a)elsie.nci.nih.gov' > Subject: Corrections to australasia zoneinfo > > The zoneinfo file I found on munnari.oz.au makes an assumption that South > Australia will follow the eastern states in moving daylight savings > forward > and correspondingly, Tasmania would not. This logic is reversed and it's > actually Tasmania which will follow the other states and South Australian > which wont be changing. > > I've included a diff patch which reflects these changes, please feel free > to > use then as you see fit. I had confirmed the time zone information as best > as I can, including the following SA government site: > > http://www.sacentral.sa.gov.au/information/daylite.htm > > Patch to apply as follows: > > 71c71 > < Rule AS 1987 1999 - Oct lastSun 2:00s 1:00 - > --- > > Rule AS 1987 max - Oct lastSun 2:00s 1:00 - > 78,79d77 > < Rule AS 2000 only - Aug lastSun 2:00s 1:00 - > < Rule AS 2001 max - Oct lastSun 2:00s 1:00 - > 100c98 > < Rule AT 1991 max - Oct Sun>=1 2:00s 1:00 - > --- > > Rule AT 1991 1999 - Oct Sun>=1 2:00s 1:00 - > 101a100,102 > > Rule AT 2000 only - Aug LastSun 2:00s 1:00 - > > Rule AT 2001 max - Oct Sun>=1 2:00s 1:00 - > > > > Regards Nick > > Nick Jeitner Ph: +61 8 8301 5342 > EDS, Client/Server Eng. Fx: +61 8 8301 5399 > 65 Conyngham St Glenside Email: Nickolas.Jeitner(a)eds.com

1 0

Corrections to australasia zoneinfo
by Jeitner, Nickolas June 19, 2000

June 19, 2000

The zoneinfo file I found on munnari.oz.au makes an assumption that South Australia will follow the eastern states in moving daylight savings forward and correspondingly, Tasmania would not. This logic is reversed and it's actually Tasmania which will follow the other states and South Australian which wont be changing. I've included a diff patch which reflects these changes, please feel free to use then as you see fit. I had confirmed the time zone information as best as I can, including the following SA government site: http://www.sacentral.sa.gov.au/information/daylite.htm Patch to apply as follows: 71c71 < Rule AS 1987 1999 - Oct lastSun 2:00s 1:00 - --- > Rule AS 1987 max - Oct lastSun 2:00s 1:00 - 78,79d77 < Rule AS 2000 only - Aug lastSun 2:00s 1:00 - < Rule AS 2001 max - Oct lastSun 2:00s 1:00 - 100c98 < Rule AT 1991 max - Oct Sun>=1 2:00s 1:00 - --- > Rule AT 1991 1999 - Oct Sun>=1 2:00s 1:00 - 101a100,102 > Rule AT 2000 only - Aug LastSun 2:00s 1:00 - > Rule AT 2001 max - Oct Sun>=1 2:00s 1:00 - > Regards Nick Nick Jeitner Ph: +61 8 8301 5342 EDS, Client/Server Eng. Fx: +61 8 8301 5399 65 Conyngham St Glenside Email: Nickolas.Jeitner(a)eds.com

1 0

hello
by JReinh7904＠aol.com June 14, 2000

June 14, 2000

To whom it may concern, My computer is on Pacific daylight savings time and I don't know how to change it to Eastern Time can you please help me out. Yours truely, Jen

1 0

Re: ACS Atlas
by Paul Eggert June 13, 2000

June 13, 2000

From: "Jamie" <jamie(a)maxnet-usa.net> Date: Sun, 11 Jun 2000 22:09:23 -0400 Doris Chase Doane has a book out on Time Changes through out the world. I just downloaded your timezone information from the ftp.btx.com site and noticed that it doesn't seem like you really have very much information. The tz database concentrates on time changes since 1970, for two reasons. First, the tz code is based on the POSIX.1 computer standard, and portable POSIX.1 time stamps cannot occur before 1970. Second, it makes the database a lot smaller if we partition the world only into locations whose time histories differ since 1970, and ignore any extra partitioning due to earlier differences. It'd be nice if someone extended the tz database backward in time to all known time stamp histories, but that would be a lot of work and nobody has done it (yet). I'm trying to create an atlas that provides the correct time zone based upon not just the date but the town and place. If you find errors in the tz database, please send email to <tz(a)elsie.nci.nih.gov>. For more complete coverage of dates before 1970, I recommend Shanks's time zone history atlases. They do not always agree with Doane, but they seem to be popular among astrologers these days. Please see: http://www.astro.com/atlas/index.html http://astrocom.com/software/ACS_PC_Atlas.htm http://astrocom.com/books/xrefa.htm#SHANKS there are frequently situations where the uncertainty about the time was actually the norm rather than the rule. You're quite right. For example, what was the time zone of Wise, Virginia on October 18, 1927? According to <http://www.astrodatabank.com/NMScottGeorgeC.htm>, Doane and Shanks disagree and in this case Doane's probably correct. Or, to take a modern example, what is the time zone of Pangnirntung, Nunavut, Canada? The province disagrees with the city, so city and commercial offices operate in one time zone and provincial offices operate on another. (How will your database address problems like Pangnirtung's?)

2 1

Timezone in Iraqi Kurdistan
by Jonathan Lennox June 12, 2000

June 12, 2000

An article in this week's Economist ("Inside the Saddam-free zone", p. 50 in the U.S. edition) on the Iraqi Kurds contains a paragraph: "With help from the UN, and protected by an air shield provided by America and Britain, the three northern provinces, although officially part of Iraq, have become the de facto state of Kurdistan, enjoying far more autonomy than the Kurds in Turkey, Iran or Syria. They use a different currency and patrol their own borders. They even switched their clocks this spring and are an hour ahead of Baghdad." Anyone know anything more about this? tzdata2000d only has a single entry for Iraq, Asia/Baghdad. -- Jonathan Lennox lennox(a)cs.columbia.edu --KAA03013.960821760/cs.columbia.edu--

2 1

Re: Electronic Shanks
by apritchard＠cix.co.uk June 12, 2000

June 12, 2000

Is the data exportable from this, does anyone know? Best wishes Alan Pritchard The GLOBAL GAZETTEER: the world on file http://www.allm-geodata.com Tel: +44 (0) 1202 417 477

1 0

Re: Java zoneinfo reader
by Paul Eggert June 7, 2000

June 7, 2000

Date: Wed, 07 Jun 2000 12:56:30 -0400 From: "Stuart D. Gathman" <stuart(a)bmsi.com> I had an elegant idea which is unfortunately incompatible with current tz format. Instead of transition times for *offsets*, the history should store transition times for *algorithms*. Yes, that's a more obvious idea, and it's probably a better one as it'll be easier to explain. (Might as well switch to XML while we're at it. :-) But I don't see why you think it's any more compatible with the current tz format than the other ideas we've talked about. All the ideas will require changes to the compiled tz files; these changes can and should be installed in a way that does not break old applications, either by installing a completely new set of tz files, or by employing unused fields in the old files.

1 0

Re: FW: Java zoneinfo reader
by Paul Eggert June 6, 2000

June 6, 2000

Date: Tue, 06 Jun 2000 18:45:29 -0400 From: "Stuart D. Gathman" <stuart(a)bmsi.com> zic would add extra "transitions" (with the same offset) when transitions are more than 2**32 secs apart. Think of it as 64 bit values with differential compression. Good point; didn't think of that. However, how would this address C code like the following? time_t t = 60000000000000000; struct tm *tm = gmtime (&t); This yields a time stamp in the year 1901324310. We can't store a table of all the transitions until then -- that'd take too much space. So if we want to handle extreme examples like this, we need an algorithmic prediction of future transitions. I realize that any prediction of future transitions will be incorrect, but the most useful prediction in practice is to use the current rules, and it'd be nice if we could support this into the indefinite future, at least for the common cases. Here's an idea. All the current tz rules are rational, in the sense that the pattern of transitions repeats after a while. So if we could append a "go back N transitions" instruction at the end of the compiled tz file, a compiled tz file could represent any set of planned transitions that a tz input file can represent.

1 0

FW: Java zoneinfo reader
by Olson, Arthur David (NCI) June 6, 2000

June 6, 2000

Stuart is not on the time zone mailing list; be sure to direct replies appropriately. --ado > -----Original Message----- > From: Stuart D. Gathman [SMTP:stuart@bmsi.com] > Sent: Thursday, June 01, 2000 5:11 PM > To: tz(a)elsie.nci.nih.gov > Subject: Java zoneinfo reader > > I have a Java implementation of java.util.TimeZone that reads the > /etc/zoneinfo database. It is not yet 2038 compliant - I propose a > solution in the docs. I will browse your site to see if the zoneinfo > database handles 2038 yet. > > http://www.bmsi.com/java/#TZ

3 3

FW: Longitute/Latitute to TIME zone
by Olson, Arthur David (NCI) June 6, 2000

June 6, 2000

Muhammad is not on the time zone mailing list; be sure to direct any replies appropriately. --ado > -----Original Message----- > From: Muhammad Safeer [SMTP:msafeer@khi.compol.com] > Sent: Thursday, June 01, 2000 7:47 AM > To: tz(a)elsie.nci.nih.gov > Subject: Longitute/Latitute to TIME zone > > Is there any formula to convert Longitute/Heading to time zone. > > Regards. > > Muhammad Safeer.

3 3