- tz - lists.iana.org

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

synthesis ?
by Antoine Leca Oct. 14, 1998

Oct. 14, 1998

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 Oct. 13, 1998

Oct. 13, 1998

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 Oct. 13, 1998

Oct. 13, 1998

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

Re: double rounding in xtime_diff()?
by Markus Kuhn Oct. 13, 1998

Oct. 13, 1998

Paul Eggert wrote on 1998-10-12 19:57 UTC: > > ``non-pathological'' = year range -9999 .. +9999 > > OK, then here's a non-pathological example of a double-rounding error: > > 1970-01-01 00:00:01.851401618 UTC > - 1970-01-01 00:00:00.000000000 UTC > > On the host that I'm talking about (sparc, IEEE, round-to-even) > your xtime_diff implementation yields > 1.851401618000000137698179969447664916515350341796875 exactly, whereas > 1.8514016179999999156535750444163568317890167236328125, which is also > exactly representable as an IEEE double, is closer to the correct answer. 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). There seem to be interesting differences between IEEE and IEEE. ----------------------------------------------------------------------- #include <stdio.h> typedef long long int_fast64_t; typedef long int_fast32_t; struct xtime { int_fast64_t sec; int_fast32_t nsec; }; double xtime_diff(struct xtime t1, struct xtime t2) { if (t1.nsec > 1000000000) t1.nsec = 1000000000; if (t2.nsec > 1000000000) t2.nsec = 1000000000; return (t1.sec - t2.sec) + (t1.nsec - t2.nsec) / 1.0e9; } int main() { struct xtime t1 = { 1, 851401618 }, t2 = { 0, 0 }; double d; d = xtime_diff(t1, t2); printf("%.60f\n", d); return 0; } ----------------------------------------------------------------------- Suggestions for a better portable implementation? A somewhat related question: Given a floating-point value X, is there in C9X a portable way to get the next smaller and the next larger floating point value? Something like the Double'Succ(X) and Double'Pred(X) built-in function attributes available in Ada <http://wuarchive.wustl.edu/languages/ada/userdocs/docadalt/rm95/0305.htm>. This might be very useful to write portable C code that is guaranteed to deliver the closest value. 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/>

2 1