- tz - lists.iana.org

new time conversion interface
by ncm＠cantrip.org Nov. 5, 1998

Nov. 5, 1998

Apologies for following up my own posting, but I don't want to lose the thread here. I have edited the quoted text below for clarity. > > Nathan Myers wrote: > > > The problem with the mktime model is that conversions between civil > > > time and timestamps can result in 2, 1, or <1 valid conversions ... > > ... it's a rare wall clock, legal document, train schedule or > airline ticket that indicates UTC offset, and when it does it's > likely to be wrong, especially during the "interesting" times. > ... > The problem that normally arises is that someone enters a date/time > and I want a numeric real-time value. I distinguish the following > troublesome cases: > > 1. It's in spring and they enter 02:30, and that time doesn't exist, > but there's a good guess (e.g. equiv. to 03:30) for what > they probably meant. (There's a corresponding case for leap > seconds.) > 2. In spring they enter 03:30, which might be correct, but they might > well have meant 04:30 because they failed to reset their clock. > 3. In autumn, they enter 01:30; did they mean the first time it > happened that day or the second? Either is equally valid. > 4. (Also in autumn) If they enter 02:30, did they mean officially > 02:30, or did they mean the second 01:30? I believe that conversions should yield a struct containing a reference timestamp, followed by up to four offsets tagged with official wall-clock offset, interpretation, and confidence values. For example, in the cases above, and ignoring leap seconds for the moment, we would get 0. Unambiguous time, e.g. 04:30 morning of a time change t0=123456789 offset 0: 0 sec; wall-clock offset: -3600 sec; interpretation: unambiguous; confidence: certain offset 0: -3600 sec; wall-clock offset: -3600 sec. interpretation: suggested substitute; confidence: doubtful 1. Spring ambiguity, enter 02:30 when it doesn't exist because civil time proceeded 01:59:59 -> 03:00:00. (Or 02:00:00 to 03:00:01? I don't know.) t0=123456789 offset 0: 0 sec; wall-clock offset: -3600 sec. interpretation: suggested substitute; confidence: doubtful 2. Spring ambiguity, enter 02:30 when it doesn't exist because civil time proceeded 01:59:59 -> 03:00:00 (or whatever). t0=123456789 offset 0: 0 sec; wall-clock offset: 0 sec. interpretation: official choice; confidence: Nominally unambiguous offset 1: -3600 sec; wall-clock offset: 0 sec. interpretation: suggested substitute; confidence: doubtful 3. Autumn ambiguity, enter 01:30 on morning when civil time proceeds from 01:59:59 to 01:00; is it the first or second 01:30 event? t0=123456789 offset 0: 0 sec; wall-clock offset: 3600 sec. interpretation: ambiguous choice; confidence: equal alternative offset 1: 3600 sec; wall-clock offset: 0 sec. interpretation: ambiguous choice; confidence: equal alternative 4. Autumn, enter 02:30, same morning as above; did they mean the official 02:30, or did they mean the second 01:30 because they failed to reset their clock? t0=123456789 offset 0: 0 sec; wall-clock offset: 0 sec. interpretation: official choice; confidence: Nominally unambiguous offset 1: 3600 sec; wall-clock offset: 0 sec. interpretation: unofficial choice; confidence: Possible alternative For each case above one might have up to two more entries corresponding to leap-second ambiguities. The detailed semantics of all the possible "interpretation" and "confidence" tags must be nailed down. This might end up looking sort of like the following C struct layout, using deliberately unsatisfactory names for exposition: typedef ... time_stamp; /* something more-or-less numeric */ typedef enum { official, unofficial, ambiguous, suggested } time_meaning; typedef enum { nominal, alternative, possible, doubtful } time_confidence; struct time_interpretation { int offset; /* limited to +/- 3601 */ long wall_offset; /* limited to +/- 43200 */ time_meaning meaning; time_confidence confidence; }; struct time_from_civil { time_stamp reference_time; int interpretation_count; /* range 0-4 */ time_interpretation interpretation[4]; }; (I've neglected leap-second ambiguity interpretations because they would reduce the clarity of the exposition.) The conversion function might look like: int time_convert(const struct tm *, const time_zone *, time_from_civil *); I think an interface like this would encapsulate knowledge about time conversion issues, exposing a high-level view of the possible real-time values implied by wall-clock time records. I think it would lead to better, more robust interfaces for conversions, and reduce programmer errors. Comments? Nathan Myers ncm(a)cantrip.org

5 5

news from Estonia
by peter＠aldie.co.uk Nov. 4, 1998

Nov. 4, 1998

My relative in Estonia reports a rather confused picture. The law is clear enough: this year they changed to the EU rule time of 01:00 UTC from their previous midnight UTC. This is a change from 04:00 -> 03:00 local time. The newspapers didn't catch up though. They were still saying it was a change from 03:00 -> 02:00 local time. They can perhaps be forgiven for this as the new law was only dated 22 September. This spring in the UK the Times (a supposed `newspaper of record') printed a picture of a clock showing it going from 02:00 to 03:00. We haven't done that since 1980. The Estonian law can be found at: http://trip.rk.ee/cgi-bin/thw?${BASE}=akt&${OOHTML}=rtd&TA=1998&TO=1&AN=1390 Knowing my poor grasp of Estonian he offers the following free translation: According to the association agreement between the EU and the Republic of Estonia ratified by the Estonian law (RT II 1995, 22--27, 120) and in accordance with the 8th directive of EU 22. July 1997, 97/44/EU (EUT L 206, 1.08.1997, pp 62--63) the Government of Estonia decides to change to Summer Time as follows 1) start 3.00 by the zone time (1.00 GMT) on last sunday of March changing to 4.00; 2) end 4.00 by the zone time (1.00 GMT) on last sunday of October changing to 3.00) I also asked him whether they use any standard abbreviation for their standard and summer times. He says no, they use "suveaeg" (summer time) and "talveaeg" (winter time). He says there is still some discussion about whether they should continue fiddling with the clocks but didn't provide any specifics. Most Estonian newspapers have web pages linked from http://www.ee/www/Media/Journalism/Newspapers/welcome.html. The papers' pages are nearly all in Estonian only so I can't offer any more clues. Finally, this just confirms the existing data. No change is needed to the europe file. Peter Ilieve peter(a)aldie.co.uk

1 0

Re: new time conversion interface
by Ian Tragen Nov. 3, 1998

Nov. 3, 1998

> long wall_offset; /* limited to +/- 43200 */ > Re. the above - I may have missed something here but if you restrict the offset to +/-12 hours, you would run into difficulties with New Zealand DST which is UTC+13h. Ian Tragen -- World Clock Page:- http://www.page-1.com/time

1 0

Time Zone Converter
by Carroll, Nancy Oct. 30, 1998

Oct. 30, 1998

To Whom it May Concern, I am writing on behalf of Manitoba Trade with respect to your database of information used to operate a time zone converter. I am working on reconstruction of our website and in particular the method of constructing a time zone converter. Do you have any sort of licensing arrangement with respect to the use of your database? Do you allow your database to be used by outside sources? Could you please forward details of the nature of your operations and whether there is any way that we might be able to draw on your database of information for our time zone utility? Thank you very much for considering my inquiry. Sincerely, Nancy Carroll Manitoba Trade

1 0

timezone database
by Roy Valdehueza Oct. 27, 1998

Oct. 27, 1998

Dear TZ, i'm glad you guys are around. If you don't mind though i'd like to ask which file on your ftp site am i going to download if i need a timezone database? And what database format is this? How is it used (or at least you can give me which file will give me the mechanics or algorithm to use this database)? Thanx a lot and advance merry Christmas! Gratefully yours, roy valdehueza

1 0

new C time interface
by Nathan Myers Oct. 24, 1998

Oct. 24, 1998

[apologies if this has been seen before.] Part of the problem with struct tm/time_t is that it works ok for inode times but not for other equally-important uses. The problem with the mktime model is that conversions between civil time and timestamps can result in 2, 1, or <1 valid conversions, and neither the user (before the conversion) nor the library is equipped to favor one result over another, or deal properly with nonexistent times. mktime offers no interface for the algorithm to report what it finds, so it must falsify its results. I hope that any interface offered to improve on mktime will expose the information needed to write reliable code. If it is also "nice" for the common ranges where there actually is a one-to-one mapping, that's a bonus, but correctness should come first. Nathan Myers ncm(a)cantrip.org http://www.cantrip.org/

2 2

Re: new C time interface
by INFOMAN Inc. Oct. 23, 1998

Oct. 23, 1998

I tend to agree with Nathan's remarks on for new C time interface. The issue, i.e. need for, correctness in conversions and linkages between (local) civil times and timestamps is one that is also raised in the context of e-commerce and e-business and needs to be resolved. Jake Knoppers <mpereira(a)istar.ca>

1 0

Re: Proposal for new ISO C 9x time API
by Markus Kuhn Oct. 16, 1998

Oct. 16, 1998

Dear Timezone Gurus, I have now revised my proposal for a new <time.h> for C, which you can find on http://www.cl.cam.ac.uk/~mgk25/c-time/ When you have some time, please let me know what you think about it. Ideally we might manage to make this the basis for a proposal for ISO C9X. In case it is already too late for that, we might at least consider implementing it in the Olsen library and publish it independently (say via IETF as an RFC, or via the POSIX project). I have also added to the end of this page a pretty comprehensive list of links to online resources relevant to the topic, and a few more will come as soon as I have access to our scanner again. Markus -- Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK email: mkuhn at acm.org, home page: <http://www.cl.cam.ac.uk/~mgk25/>

9 50

Re: Proleptic Gregorian and "Proleptik Julian xtime"
by INFOMAN Inc. Oct. 16, 1998

Oct. 16, 1998

The attached file "prolep.doc" is the extract from the entry in the Oxford English Dictionary (Second Edition) on Compact Disc. It may interest you all to know that Oxford records "proleptik" in use in Medieval times as meaning "predictive, prognostic" or "of the nature of a pre-assumption; pre-conceived; apriori; axiomatic"...etc. Nathan Myers is right when he states "proleptic" refers to the future not the past. The question is how far into the future to predict as can be noted in the following quotation in Oxford of pre-POSIX xtime calendar standardization efforts to determine the date at which God created the earth. Usher (1658) "Having placed therefore our heads of this Period in the Kalends of January, in that proleptik year, the first of our Christian vulgar account must be reckoned the 4717 of the Julian Period". This having been noted it is interesting that as we approach the 2nd millenium , we again have a "proleptic" debate. Jake Knoppers

1 0

Re: Proleptic Gregorian (was Re: Functions add/diff/cmp for xtime)
by Rich Wales Oct. 15, 1998

Oct. 15, 1998

Antoine Leca wrote: . . . TIME_TAI *or* TIME_UTC (as defined by Markus, with the added point that the calendar should be the proleptic Gregorian). Markus Kuhn replied: Question: What precisely does "proleptic" mean and where is it defined? . . . (I suspect it means "extended before the time it was defined", but would like to get a confirmation and reference.) Short answer: My understanding agrees with Markus's suspicion. Longer answer: I looked up the word in two respected American English dictionaries: the Webster's Ninth New Collegiate Dictionary (1985), and the American Heritage Dictionary (New College Edition, 1976). Webster's New Collegiate defines "prolepsis" (a noun) as "the represen- tation or assumption of a future act or development as if presently existing or accomplished", or "the application of an adjective to a noun in anticipation of the result of the action of the verb". "Proleptic" is listed as the corresponding adjective. The American Heritage defines "prolepsis" as "the anticipation and answering of an objection or argument before one's opponent has put it forward", or "the use of a descriptive word in anticipation of the act or circumstances that would make it applicable". It lists both "pro- leptic" and "proleptical" as adjective forms. Both dictionaries say the word is derived from Greek "prolambanein" (to take beforehand) < "pro-" (before) + "lambanein" (to take). Webster's New Collegiate says the first recorded use of the word in English was in 1578. So, the "proleptic Gregorian" calendar would be the result of extending the Gregorian calendar back into the past, before it came into use in a given location, or even before it was invented. My sense (as an educated native speaker of American English) is that "proleptic" and "prolepsis" are not commonly known or used by the aver- age English-speaking person. English is, of course, replete with such words, known primarily by authors, orators, and Scrabble players. Rich Wales richw(a)webcom.com http://www.webcom.com/richw/

4 3