October 1998 - tz - lists.iana.org

Time Zone Converter
by Carroll, Nancy 30 Oct '98

30 Oct '98

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 27 Oct '98

27 Oct '98

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 23 Oct '98

23 Oct '98

[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. 23 Oct '98

23 Oct '98

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 16 Oct '98

16 Oct '98

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. 15 Oct '98

15 Oct '98

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 14 Oct '98

14 Oct '98

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

synthesis ?
by Antoine Leca 14 Oct '98

14 Oct '98

I believe we should try to advance beyond the points of disagreement exposed by some of us. I think the main point of disagreement is about the format of the basic type to be used for holding time. On one side, Clive Feather proposed an improvement over struct tm. OTOH, all others proposed improvements over time_t. If we followed this later way, I think we can classify all the possible implementations in the following order: 1st, those implementations that know both UTC and TAI "perfectly". I think this is the kind of implementations David has in mind. It is certainly the current case of tz-based up-to-date machines. It will also be the general case of the up-to-date boxes with Internet connection in a near future, IF our plan passes in C9X! 2nd, those implementations where the clock is UTC based and that have some knowledge about leap seconds, but where the famous table is not known to be correct. As Markus highlighted, and fears, this case is in my mind common, and should not be impaired too much; but it is only 2nd class. 3rd, those implementations that only know about UT, without any precision, and that don't know about leap seconds; in fact, it is like many informed people, or like Posix. 4th, worse, those implementations that even do not know about time zones, and that only know "some form of local time". Like Ms-Dos. 5th, if it even exists, those that cannot figure what time is it. I doubt it really exists, but traditionnaly C handles them. My idea is that the API to be proposed should work OK and smoothly with all classes, with priority given to the highest class(es) where there are choices to make. The main point is that everything (except the last class!) ends up as counts of seconds, and sometimes subseconds; but having to manage 2 functions for each functionnality seems too much for me; therefore I prefer something along the lines of struct taia or struct xtime. Not specifying what real kind of time counter is used is fairly frequent in the C standard: it is said to be unspecified. Sometimes, Markus's xtime_conv would then permit to convert this unspecified format to some other its application is aimed at (we have now numerous examples of applications where either TAI, either UTC or decomposed Gregorian are better fitted ;-) ). Can it works? Antoine

2 1

Re: double rounding in xtime_diff()?
by Marc Lehmann 13 Oct '98

13 Oct '98

On Mon, Oct 12, 1998 at 11:24:06AM +0100, Markus Kuhn wrote: > That's very interesting. Under Linux/Pentium_II (cpu=686, model=3, > vendor_id=GenuineIntel, stepping=4, gcc 2.7.2.3) the effect does not > show up immediately. I had to enforce using the software FP-library with > gcc -msoft-float to reproduce this effect, because without this option > with the hardware FPU I get the correct result (and this is apparently > not thanks to Intel's internal 80-bit arithmetic, because I did use gcc > -ffloat-store to enforce 64-bit rounding). Have you looked at the actual assemby output? x86 is the worst platform to "prove" something about double arithmetic. Unless you set the cpu to double rounding mode (say, using __setfpucw), therefore invalidating long double, nothing will help. -ffloat-store does not do what you want in every case. > There seem to be interesting differences between IEEE and IEEE. No, but between IEEE and x86 ;( > A somewhat related question: Given a floating-point value X, > is there in C9X a portable way to get the next smaller and the You could (in C90 as well) try to mess around with frexp/ldexp and/or scalb. The draft c9x standard (as well as xopen-extended) seems to contain a "nextafter" function: nextafter (x, y): Return X + epsilon if X < Y, X - epsilon if X > Y. -----==- | ----==-- _ | ---==---(_)__ __ ____ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / pcg(a)goof.com |e| -=====/_/_//_/\_,_/ /_/\_\ --+ The choice of a GNU generation | |

1 0

leap.yp.to
by D. J. Bernstein 13 Oct '98

13 Oct '98

As an experiment I've set up a TXT record in DNS for leap.yp.to with a year-by-year history of leap seconds since 1972. On a UNIX machine try nslookup -type=txt leap.yp.to or dig txt leap.yp.to It's easy to do this automatically every May and November, and to convert the results to libtai's /etc/leapsecs.dat format. ---Dan 1000 recipients, 28.8 modem, 10 seconds. http://pobox.com/~djb/qmail/mini.html

1 0