- tz - lists.iana.org

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

Re: xtime/libtai/"right"
by Nathan Myers Oct. 12, 1998

Oct. 12, 1998

> But as noted by Bradley and David before, this is not a problem when > you are only talking about inode times. Since when are we only talking about inode times? Part of the problem with 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. After a conversion, if all the results are exposed the client has the information necessary to make an informed choice. 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. Nathan Myers ncm(a)cantrip.org http://www.cantrip.org/

1 0

Re: xtime/libtai/"right"
by Bradley White Oct. 12, 1998

Oct. 12, 1998

>> I think if we all stipulate that some form of "display UTC" is the >> only representation that should be stored or forwarded, > You expect high-volume logging tools and network servers to convert > every timestamp to year-month-day-hour-minute-second-subsecond? I only expect entities that wish to exchange timestamps with other entities to convert them to a "display UTC" equivalent representation, which does not imply such a full breakdown. It is up to the protocol designer to choose the "display UTC" representation, and it is up to the local system to choose the timestamp representation. Both parties will undoubtedly want to make choices that simplify any conversions. [It would also be possible for the protocol to negotiate a mutually acceptable representation to avoid any conversions, but everyone should accept the "display UTC" equivalent.] > What exactly is the benefit of these conversions? The benefit is the separation of local and remote representations. Might I liken it to exchanging floating point values? > you're kidding yourself if > you expect UNIX filesystems to start storing inode times in that format. I only expect them to store something equivalent to "display UTC". [POSIX time_t's fail to represent leap seconds. People seem to dislike struct xtime because of the ability to represent bogus leap seconds. TAI requires a leap-second table.] So choose any flavour you like locally, but don't force that choice upon those you communicate with. And recognize your shortcomings (for example, POSIX-time_t based file systems screw up file time orderings during leap seconds).

4 3

Functions add/diff/cmp for xtime
by Markus Kuhn Oct. 12, 1998

Oct. 12, 1998

Several commentors have expressed a desire to have a few basic predefined arithmetic functions on xtime values. I suggest to add the following three functions. These functions are so simple that I feel the easiest way of specifying their behaviour is by providing a sample implementation (i.e., using C as the specification language instead of English): ------------------------------------------------------------------------ /* * Assertions: * * fabs(xtime_diff(xtime_add(t, d), t) - d) <= 0.5e-9 * for all t, d with fabs(t.sec + d) < 2**62 and t.nsec in the valid range * * xtime_cmp(xtime_add(t, d), t) * is in the set {-1, 0, 1} and has the same sign as d or is 0 iff d==0.0 * */ int xtime_cmp (struct xtime t1, struct xtime t2) { if (t1.sec == t2.sec && t1.nsec == t2.nsec) return 0; if (t1.sec > t2.sec || (t1.sec == t2.sec && t1.nsec > t2.nsec)) return 1; return -1; } 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; } struct xtime xtime_add(struct xtime t, double d) { double ds; if (t.nsec > 1000000000) t.nsec = 1000000000; t.nsec += floor(modf(d, &ds) * 1.0e9 + 0.5); t.sec += ds; while (t.nsec >= 1000000000) t.sec++, t.nsec -= 1000000000; while (t.nsec < 0) t.sec--, t.nsec += 1000000000; return t; } ------------------------------------------------------------------------ Note that concerning leap seconds, the arithmetic functions follow exactly the spirit of the TIME_UTC definition and do not count inserted leap seconds as time worth counting. So even if there is an inserted leap second 1972-06-30 23:59:60 UTC the xtime_diff difference between 1972-06-30 00:00:00 UTC and 1972-07-01 00:00:00 UTC is still precisely 86400.0 seconds. This allows you to use time intervals such as 86400.0 in order to mean "one day later" on the UTC clock, which is what most applications need (and what POSIX provided so far). Note that I also have carefully defined the behaviour of the function for the case that they operate inside leap seconds to conform to this model and to fulfil the - I think - desireable algebraic property that I specified in the assertion. If you are *really* interested in the number of SI seconds between two UTC timestamps (very few applications will really need this, and those usually will better use TIME_MONOTONIC instead of UTC), then just convert both via xtime_conv() into TAI timestamps (assuming the information is available), and then use xtime_diff on the resulting TAI timestamps: if (!xtime_conv(&tai1, TIME_TAI, &utc1, TIME_UTC) && !xtime_conv(&tai1, TIME_TAI, &utc1, TIME_UTC)) return xtime_diff(tai1, tai2); else { /* relevant leap second history not available */ } Very simple, very intuitive, very robust, very clear semantic, and very straight forward. *** I love it. *** :-) Other questions: Has anyone made some experiments or can contribute arguments to decide on whether passing 96-bit structs by pointer or by value is more desirable? Has anyone completed the UTC part of the xtime_make() specification code in the proposal or do I have to do this myself? Is anyone willing to merge the xtime text with the existing C9X draft and also include the change requests that Paul submitted to ANSI? Any suggestions regarding the sample code of the above functions? 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 37

Re: Proposal for new ISO C 9x time API
by Ken Pizzini Oct. 12, 1998

Oct. 12, 1998

In tz(a)elsie.nci.nih.gov message , Antoine Leca <Antoine.Leca(a)renault.fr> wrote: > > Surely we > > could think of some other, perhaps even more suitable, name > > for this? Some ideas: > > struct moment > > struct instant > > struct beat > > struct clock > > struct chronos > > struct tiempo > > struct heure ... > > (From this list, I somewhat favor "chronos".) > > Me too. > However, it may not fit well with the rest of the API, > which is clearly English-biased. Well, IMO that is largely a historical accident; since we are discussing an international standard I'm personally not too interested in enforcing that the language maintain a distinct English bias. And the Greek word chronos (Kronos) is used in English as the combinitive form "chrono-" in several words; provincial English speakers should have no problem understanding the time-related meaning of "chronos". Then again, perhaps it is better to stick with "pure English"; I don't know. > OTOH, struct time is available, too. Yes, but we still need a name to substitute for the xxx of strfxxx(), and "time" _is_ taken there. --Ken Pizzini

6 11

Re: turning clocks back
by Dik.Winter＠cwi.nl Oct. 11, 1998

Oct. 11, 1998

> Actually thinking about it, there is a neat way of encoding hour 2A in a > distinguishable way even on "analog" clock displays: Just stop the > motion of the hour pointer for 60 min during hour 2A, and it will be > immediately recognizable whether you are in hour 2A or 2B (except > perhaps for the first few minutes of the hour, where the smaller pointer > hasn't moved yet much during hour 2B). Well, for clocks I do not think it matters as much as that. Since the days that DST was introduced in the Netherlands (the 70s), in Amsterdam the switch over of public clocks was done by letting them run at half speed or at double speed during an hour. As far as I know nobody did complain (but perhaps nobody is using those clocks as they are always a few minutes slow compared to the clock the Dutch railways uses?) I seriously doubt the "second exact" time some people say they need on their watches. But who am I, I do not have a watch. dik -- dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131 home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

1 0

Definitions of date arithmetic
by Joe Celko Oct. 11, 1998

Oct. 11, 1998

>> What is 1 month before 31 March? What is 1 month before 16 March? What is 1 month before 1 March? What is 1 month after 1 February? What is 1 month after 16 February? What is 1 month after 28 February? << The ANSI X3H2 Database Standards committee looked at this and found that GAAP (Generally Accepted Accounting Practices) and other commercial users of date arithemetic all disagreed on how to handle months in expression. For example, there are over 150 fiscal years, each with slightly different rules for this. The Bond trade says a month is always 30 days, etc. etc. Our solution in the SQL-92 standard was to only define math with interval units of one day or less. Anything more than that was up to the user. --CELKO--

2 1