October 1998 - tz - lists.iana.org

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. 11, 1998

Oct. 11, 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

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

Oct. 10, 1998

>> TAI requires a leap-second table. > Nonsense. > > It is true that CONVERTING between civil times and numeric TAI64 times > requires knowledge of leap seconds, the calendar, time zones, etc. Oops ... you're right ... I did not explicitly state the "conversion" my message was referring to within that sentence. I hope that didn't confuse too many list members. Thanks for the correction.

1 0

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

Oct. 10, 1998

Allow me to clarify two responses: >>> 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? A server that just accepts, stores, and distributes timestamps would simply store them in wire format. No conversions would be required. Only clients need interpret those "display UTC" convertible timestamps. >> you're kidding yourself if >> you expect UNIX filesystems to start storing inode times in that format. I certainly don't expect UNIX filesystems to start storing "display UTC" convertible timestamps anytime soon. But I think it will happen eventually. The only issue that has stopped Olson "right" mode from being more popular is its failure to clearly distinguish between its TAI-ticking time_t's and the POSIX time_t's calculated or received from elsewhere. My observations about internal and external representations are based upon that practical experience. Thanks.

1 0

xtime/libtai/"right"
by Bradley White Oct. 10, 1998

Oct. 10, 1998

] Much discussion about the representation of timestamps, the ] inability to predict future leap seconds, and the effects of ] out-of-date leap-second tables, I think if we all stipulate that some form of "display UTC" is the only representation that should be stored or forwarded, then some of the objections will disappear. If anyone wants to define such a "display UTC" representation for files or communication protocols, so be it. [Personally, I would just use an ISO string and eat the conversion and storage costs.] Otherwise, the local representation of timestamps is a local issue, and we should just be specifying an API to manipulate such timestamps in useful ways. [I'm not sure if making them arithmetic would be a advantageous step in that process.]

2 1