- 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

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

Re: Proposal for new ISO C 9x time API
by Bradley White Oct. 10, 1998

Oct. 10, 1998

> Ever watched xntpd > try to handle a leap second? Wobble, wobble, wobble, wobble, wobble. NTP on an "Olson-right" system, with the addition of a single time2posix() call, sails smoothly through a leap second by ignoring the leap warning indicator and all its convoluted logic.

2 1

Re: Functions add/diff/cmp for xtime
by Canaglobe International Inc. Oct. 9, 1998

Oct. 9, 1998

On the three simple arithmetix function proposed by Markus, Clive asked "If so simple why bother?" I would note that why should everyone always be forced to reinvent the wheel? What is simple to experts is complex to others. Users very much welcome "sample simple solutions" developed by expert. Common use of simple (standardized) solutions facilitates interoperability and reduces ambiguity. Jake Knoppers

2 1

[QingLong <qinglong@Bolizm.ihep.su>] Ufa timezone.
by Ulrich Drepper Oct. 9, 1998

Oct. 9, 1998

Thanks for the input. I forward your patch with this mail to the appropriate people. I'm only using the work in glibc. ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------

3 2

is tzcode localtime_r() missing a call to tzset() ?
by Donald Johnson Oct. 7, 1998

Oct. 7, 1998

Greetings, I've checked the past few versions of tzcode1998?.tar.gz and all seem to code localtime_r() without a call to tzset(). This doesn't seem right. don.

2 1

Proleptic calendars
by John Cowan Oct. 7, 1998

Oct. 7, 1998

Here's another specific reference, from http://www.magnet.ch/serendipity/hermetic/cal_stud/cal_art.htm#Proleptic # Every date recorded in history prior to October 15, 1582 (Gregorian), # such as the coronation of Charlemagne as Holy Roman Emperor on # Christmas day in the year 800, is a date in the Julian Calendar, since # on those dates the Gregorian Calendar had not yet been invented. # We can, however, identify particular days prior to October 15, 1582 # (Gregorian), by means of dates in the Gregorian Calendar simply by # projecting the Gregorian dating system back beyond the time of its # implementation. A calendar obtained by extension earlier in time # than its invention or implementation is called the "proleptic" # version of the calendar, and thus we obtain the Proleptic Gregorian # Calendar. The Julian Calendar also can be extended backward as the # Proleptic Julian Calendar. # For example, even though the Gregorian Calendar was implemented on # October 15, 1582 (Gregorian) we can still say that the date of the # day one year before was October 15, 1581 (Gregorian), even though # people alive on that day would have said that the date was October 5, # 1581 (the Julian date at that time). As another example, the date # of the coronation of Charlemagne, December 25, 800, in the Julian # Calendar, was December 29, 800, in the Proleptic Gregorian Calendar. -- John Cowan http://www.ccil.org/~cowan cowan(a)ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5)

1 0

Y2K: it's worse than you think
by John Cowan Oct. 7, 1998

Oct. 7, 1998

Between the Y2K meltdown on 2000-1-1 and the Unix meltdown on 2038-1-18, the world of computing will have to scramble hard to cope with the Mayan Long Count meltdown on 2012-12-21 or 2012-12-23 (accounts differ), when the Long Count will return to its zero point of 13.0.0.0.0 (the first component is numbered 1-13 rather than 0-12) for the first time since 3114 B.C.E. Is *your* software ready for it? -- John Cowan http://www.ccil.org/~cowan cowan(a)ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5)

1 0

Re: Fw: Time Zone Names
by Canaglobe International Inc. Oct. 6, 1998

Oct. 6, 1998

The 3-digit time zones are stable they change only when there is a change in jurisdiction (.e.g. the break-up of the Soviet Union, Yugoslavia, Ethiopia, etc.) led to the creation of new jurisdictions. One key attribute of these jurisdictions is that they now become the authority/source for establishment/declaration of time zones, switches to daylight saving time, etc. Consequently, changes in 3-digit numbers represent either additional objects in the same object class or significant changes to existing objects in the object class. The two and three alphas are merely human interface attributes of each instance of an object. These human interface attributes can and do change depending on the will of the authority/source as do the associated names. However, the assignment of numeric codes is linked to international recognition of changes in jusrisdictions and handled through the United Nations. On this there is a liaison from the UN Statistical Office to DIN the registration authority for ISO 3166. In short, the following rule-base applies, (1) changes to the numeric codes in ISO3166-1 occur only when agreed to by the UN where its member bodies collectively recognize the addition of a new jurisdiction and/or changes in existing jurisdictions particularly where these involve physical boundaries. (2) Time zones are physical boundary oriented and one needs to have unambiguous identification and referencing in a linguistically neutral and IT-enabled manner of of the authoritative sources stating the rules for each disrcete time zones (3) ISO 3166-1 countries identified through their numeric codes as assigned via the UN and disseminated through DIN provide such unambiguous identification and referencing (4) ISO 3166-1 countries have the authority within this schema, i.e. UN + ISO 3166 rules, to attach whatever names they wish to their entity including 2 and 3-alpha codes as long as these have not already been taken by other entities, i.e. instances of objects in the same class. (5) ISO 3166-1 countries have the authority to identify and label their 3166-2 level object as they see fit including delegated authority, if they so wish, with respect to jurisdiction over time zones in the physical territory referenced through an 3166-2 code. Personally, I find it surprising and a bit disconcerting that those who are taking so much time and effort in identification of time zones, their properties, etc. would take such a cavalier attitude to the unambiguous identification and referencing of the authorities/sources of the same. If we are ever to have a referenceable "database" on date/timezones as Marcus Kuhn is thinking and I see David Keegel also sees as a long term objective, we should take this matter a bit more seriously, i.e. the IT-enabled and IT-interface API versus the multiple human interface equivalents which it may have. Enough said - Jake Knoppers <mpereira(a)istar.ca>

3 2

Re: big-picture comments on your proposed extensions to ISO C <time.h>
by Markus Kuhn Oct. 6, 1998

Oct. 6, 1998

(I hope you don't mind Paul, if I reply on tz) Paul Eggert wrote on 1998-09-29 01:34 UTC: > Here are some big-picture comments on your proposed extensions to ISO > C <time.h>. I've hacked up a copy of your HTML proposal along these > lines, if you're interested in reading it. (I still don't have a > revised rationale, though.) > > It's very hard work to come up with a good spec! After trying my hand > at it, I respect the work you've done so far; the following comments > are in the spirit of improving it to be as useful as possible. > > I have some more detailed comments once you've had time to digest > these bigger-picture comments, but first things first..... > > * Terminology proposal: let's rename `xtime' to `stime' (short for > ``standard C time''), uniformly. The rest of my discussion assumes > this new terminology. Hm, see my separate posting on the many different renaming proposals that I received. > * struct stime is inconvenient for programmers. It's hard to portably > subtract such values, much less do other arithmetic on them. Even > comparing them is error-prone. This structure's members are derived > from a similar structure in POSIX.1, but the POSIX.1 structure was > predicated on not having integer types longer than 32 bits. > > Instead, let's just use a signed integer count of the number of time > intervals since the epoch. We can define a type stime_t for this > integer, and a stime_t macro STIMES_PER_SEC giving the number of > time intervals per second. This makes time arithmetic much, much > easier. I am afraid, but I strongly disagree here. I think my current approach is more robust, functional, and therefore preferable. The reason: Most C 9X implementations will not provide any type with more than 64-bits. If we take a 64-bit type, then you can have only nanosecond resolution over an interval of 58 years. This is unacceptable; even the notorious Y2K COBOL programs fail only after 99 years. Note that this is independent of whether you use a 64-bit int or a 64-bit float type, 64-bit is just not enough for a high-resolution timestamp. About the "convenience" argument in general (and I'll come back to this for Antoine's xtime_get return value critique): Compared to modern programming languages with their variable length arrays, exceptions, garbage collectors, controlled name spaces, etc. C is and will always be a comparatively simple and quite inconvenient early-1970s language. If you want convenience, look for another language than C. The interesting thing about C these days is mostly that it is ubiquitously implemented. Most programming environments for more modern and comfortable languages are built on top of the existing C API. If you read the C++, Java, and Ada95 standards, then it becomes embarrassingly obvious that the abilities of their standard library has been limited by the existing ability of the C library, therefore is is extremely important to get the functionality of the C API right. The comfort should certainly come after functional criteria. I do not understand, why it should be difficult to portably add and subtract struct xtime values. The new <stdint.h> offer a reasonably good support here. The algorithm is trivial: Before any arithmetic, you first check whether there is a leap second in one of the arguments and abort if there is (because arithmetic is ill-defined in this case). Then you just add sec and nsec separately and adjust for the nsec overflow. Note that non-leap nsec values do not overflow the nsec type, because 2 * 1e9 < 2**31. It all fits so nicely together with nanoseconds, I couldn't think of a more appropriate representation. The POSIX.1b people made certainly a good choice here. In programming languages such as C++ or Ada where operators like "+" and "-" can be overloaded, the authors of bindings to the xtime API will certainly add the corresponding overloadings, and then xtime is as easy to use as a float type. If you insist, we could add macros or functions for struct xtime arithmetic, but I think it is better to let users do this themselves to make sure they have thought about the leap second aspects of arithmetic, which are certainly application dependent. (Again, the lack of an exception mechanism in C prevents to do a robost and comfortable interface at the same time, so we stay on the robust side and leave to comfort to languages with proper mechanics to do it.) How would you represent leap seconds in your stime_t arithmetic type? This was after all besides the resolution concerns the major reason for getting rid of time_t and its idea of using an arithmetic type. > * We should pass timestamps by value whenever possible, instead of by > reference. Passing timestamps by reference makes the program more > error-prone and (these days) slows it down. This is particularly > important for stime_get. That is an interesting point. Actually, I have never done any measurements on whether passing a 96-bit struct by reference is more efficient than passing it by value with the usual C compilers. Does anyone have any numbers on this for typical 32-bit processors? For stime_get however this is not an option: the return value is certainly required for comfortable error checking. Other programming languages with exceptions could probably return the time value here, but in C we have no exceptions and therefore (as xtime_get can fail), we will have to use it in some form of if statement with an explicit exception handler. > * We should constrain the implementation to support times through a > reasonable upper bound (e.g. 9999 AD, or perhaps something a bit > sooner since we'll have to reform our calendar well before then). > But we shouldn't insist on astronomical timescales; that places > an undue burden on the implementation. What would this burden be? We know that 32-bit is too small, and the next best size is 64-bit words or with nanoseconds a 96-bit struct. The last non-power-of-two machine that I worked on was dumped >10 years ago and never had a C compiler. These are of academic interest. There is no practical intermediate size between a useful range and a 64-bit second counter. I think it is much more of an burden for the application programmer in the end to leave the time encoding and epoch undefined. > * We should specify better what happens before the epoch for TIME_UTC > and TIME_TAI. Actually, I would suggest that we specify the functionality of a xtime_make(&xtp, &tmptr, NULL); call completely by providing an example of a correct implementation in the standard (should be possible in less than 50 lines). Real code is much clearer here than any pseudo-mathematic specification. I started to add such example code to my web page a few days ago, but was interrupted and didn't get around yet to finish. Volunteers are welcome (especially getting the leap year formula for negative years correct might be a bit of a brain tweezer). Such example code resolves many ambiguities and also should solve your concern here. As far as TIME_TAI is concerned, I do not expect *ANY* implementation to support xtime_conv with pre-1972 TIME_TAI values. The other functions do not care about the difference between TIME_TAI and TIME_UTC anyway, and the semantics of the TIME_UTC clock relative to the Gregorian calendar withh be specified in the example code. > * We shouldn't insist on a particular type like `int_fast64_t' for > timestamps. I assume that this type was chosen to encourage > portability, I chose it for range and efficiency and fortunately. With int_fast64_t C provides me with exactly what I had in mind. I am not sure what type of portability you are referring to. > but it's not truly portable, since int_fast64_t might > have more than 64 bits. Please explain what the problem would be there. I don't see any. > Also, as mentioned above, it's way way > overkill for almost all applications. It's better to keep the > timestamp type a bit more abstract, like stime_t, and to place > constraints on it as needed, as described above. The abstractness of types like time_t in ISO C 89 was not done because this abstractness was considered to be good and beautiful design. On the contrary, is was a necessary hack because the ISO C standard had to be backwards compatible with a few strange C implementations. In this respect, ISO C 89 was a step backwards compared to K&R C. (Special thanks to Nick Maclaren <nmm1(a)cus.cam.ac.uk> for providing me with the historic background on this.) To my big surprise, many people today start to admire the hacky type mess that ISO C had to introduce because of bad PC compilers as glorious and wonderful abstractness, having completely forgotten the original reasons for all the awful type-uncertainties of ISO C 89. > * The stime_get interface is confusing, since it has several > operational functions. It's better to separate them out into one C > function for each operational function; e.g. we should have a > separate function stime_getres to get the resolution, instead of > passing a flag to stime_get to have it return the resolution instead > of the current time. Similarly, we should have a separate function > that gives us an error bound on the clock, rather than have a > TIME_SYNC flag. I considered defining several functions, and then deliberately packed all these functions into a single one. The main reason is that this packing of functionality allows implementors to add more functionality by just giving additional option and return bits a meaning, without cluttering up the namespace in non-portable ways. My proposed xtime_get interface allows you to add additional clocks to be requested (UT1 is one example I mentioned in a note in the proposal), or allows additional data to be requested (like is the clock coming in over a trusted channel, when was the last connection to this clock, estimated error interval size, etc.). I prefer to have a single more universal function that provides a clear way of addition additional functionality in a portable way over a set of functions that leave no room for extensions. It is always easy to add another biot, but is is difficult to add another function in implementations in a binary compatible way (thinking about shared libraries and these issues). > * We should require at least POSIX-style time zone specifications for > tz_prep, and should suggest Olson-style. As things stand, there's > little that portable code can do with that function. Requiring POSIX-style time zone specifications as a minimum functionality would be ok for me, but so would be to leave the string completely application defined and just mentioning POSIX as one possible implementation. I don't know whether the Olson-style ones are standardizable unless we get some sort of official ISO registry for time zone specifications. As I have pointed out before, I don't like the continent prefix in the Olson/style names, therefore I do not want to make this particular syntax immortal in an ISO standard (I much prefer just ":Paris" over "Europe/Paris"). Note that the tzstring will usually be directly entered by the user (say via a config file or via an environment variable), and the portable application does not have to be aware of the syntax used on this system. > * We should codify the convention that getenv("TZ") returns the > user-preferred time zone. A null tzstring should expand to a > system-defined time zone. This functionality is in practice and is > useful e.g. in mailer software, where you may or may not want to > allow the user to specify the time zone. OK, that sounds like a good idea. > * stime_make still has the old mktime problem that the function can't > distinguish a request for ``3 days after Feb 28'' from a request for > ``1 month before Mar 31''. It's silly that mktime thinks that 1 > month before Mar 31 is Mar 3 (or 2, if it's a leap year). We should > fix this. I think I fixed this very nicely by not requiring xtime_make to handle *any* invalid time representations. If you want 3 days after Feb 28, then you just add 3 * 86400 to the sec field. The extremely ugly hacks with mktime overflows and underflows have become obsolete by defining the encoding of the time representation to allow direct arithmetic. It is very difficult to define mktime overflow behavior nicely, so why bother if there is no need? > * The proposal for strfstime still involves magic; e.g. how can the > strftime easily determine the time zone abbreviation? strfxtime gets the timezone object passed as a paremeter. All information can be stored in there and accessed directly. No need to extend struct tm. > I'd rather > have a strftime that could in principle be written by the user; it's > common practice to write augmented strftime implementations, which > grind their teeth over questions like these, and it'd be better if > we let people write such functions cleanly. If you need access to the zone name, then simply use strfxtime to access it. I don't understand why it should be stored in any struct tm extention if we have a function to read it. > This will involve a new > type `struct stm' that contains extra members so that no more magic > is needed. Something like this: > > struct stm { > stime_t year; > int month; > int month_day; > int hour; > int minute; > int second; > stime_t utc_offset; > stime_t dst_offset; > const char *zone; > const char *zone_description; > }; No, please no additional structs. The existing one is good enough to represent and handle a full broken-down time. All other information is fully accessible via strfxtime. I consider the mixture of brocken-down time and timezone information conceptually dubious. For me a time zone is a function that maps broken-down times onto UTC, and not just auxiliary data on a broken-down time. The existing tm_isdst field seems to me to be sufficient (although not optimal) to handle ambiguities. > * We shouldn't have a separate error function just for stime. Instead, > functions that report errors should yield an error number, which can > be passed as an argument to strerror. This will simplify the interface > (e.g. we don't need to worry about LC_MESSAGES). That's perhaps worth thinking about. It depends on how detailed you want to make these error messages, and whether a single number can carry all information. Timezone strings can be rather tricky to get right and a comfortable diagnostic might be useful here. Thanks for your comments. 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/>

5 13

FW: tzcode1998h.tar.gz and tzdata1998i.tar.gz (corrected)
by Olson, Arthur David (NCI) Oct. 5, 1998

Oct. 5, 1998

(The name of the "data" file was incorrect in the letter sent out last Thursday; thanks to all who noted the error.) The files ftp://elsie.nci.nih.gov/pub/tzcode1998h.tar.gz and ftp://elsie.nci.nih.gov/pub/tzdata1998i.tar.gz are now available. These incorporate the changes for Brazil, Chile, and Germany circulated on the time zone mailing list earlier this week; also included is support for use of "24:00" in the input files for the time zone compiler. --ado

1 0

Fw: Time Zone Names
by Canaglobe International Inc. Oct. 4, 1998

Oct. 4, 1998

I find this discussion on time zone names interesting as well as the example of the country code qualifier. It highlights a large issue, namely that of unambiguous identification and referencing of "time zones" and in an IT-enabled manner. In addition, it is likely that e-commerce will make increasing use of date/time stamps in business transactions(e.g. closing date/time for bid is XXX local time, or an identified/referenced time zone) and the same in relation to digital signatures, certificates, key management, etc. Attached is a Canadian contribution to ISO standardization work of relevance to this discussion and relates issues. Normally, I would have provided the URL but access to the ISO/IEC JTC1/SC32 web site requires User ID and Password. Thus I attach a copy as a Word doc. Let me summarize three key points: 1. In standardization work in relation of Open-edi, e-commerce, geomatics, etc., one is becoming increasingly aware of the need for unambiguous, unique and linguistically neutral identification and referencing of "objects". As found in ISO 1087 "name" = "designation of an object by a linguistic expression". Consequently, any object will (1) have multiple names and (2) many of the "names" used to designate a real worl "object" will be in the form of linguistic expresions which use -non-Latin characters (e.g. Arabic, Chinese, Hebrew, Japanese, Cyrillic, etc.) This is one reason why ISO/IEC 106464 (a.k.a.) will become a key IT-infrastructure standard. Thus "names" can be and are used to designate an object, they are not that useful for unambiguous identification since often a name, i.e. a character string (or alpha/neric string), is not unique. Here "Paris" provides an example of several different real world objects having the same name.[ A problem known as "polysemy"] We can add qualifiers and will likely do but here I suggest cross-sectorial approach for refrencing rather that each area doing its own thing. 2. It is my understanding that the problem of multiple linguistic expression for the same geographic place name( e.g. London, Londres, Köln, Keulen, Cologne, Germany/Deutschland/Allemagne, etc.) is being addressed by topnomy experts world-wide through the UN (I need to check this out but maybe one of you knows more about this). It is my understanding that in the end there will only be one single official name for each place in each country in the language of that country as decided by the toponomy commission in each country. Where the language of that country uses a non-latin alphabet character set, that country is also expected to provide one single Latin-alphabet based equivalent name. In Canada, which is a biligual country (English/French), existing bilingual place names are disappearing in favour of uniligual ones, i.e. English or French (e.g. Trois Rivières/Three Rivers is now only Trois Rivières). Further in Canada (and likely inother countries as well), each place name, whether point, area/polygons or linear (e.g. rivers), is assigned a single lat/long coordinate for referencing purposes. (For larger cities, lakes, provinces, etc. this is an "abitrary" point, for river is is a lat/long coordinate take from the headwater, etc. Where map surrounds/polygons delienate the boundaries, these can then be referenced. In conclusion there is/should be a linkage here to the manner in which one references time zones. (See further the National Atlas of Canada and its Canadian Geographic Names Data Base) 3. The ISO 3166 standard Parts 1 and 2 is not IT-enabled, the two letter alpha codes are not stable can and do change (The IANA and Internet domain names also has to address this problem but then underneath all the Internat names are the numeric codes used for the actual routing and addressing among the ISPs, IT-systems, etc.). The ISO 3166 the three digit numeric country code is the most stable and also unique. The two alpha country codes often gets mixed up with the two letter language codes and the three letter alpha country codes with the three letter currency codes. They are not the same and often not unqie. All these and related problems which human beings used to filter out or write special programmes for to handle are now coming out in spades via everyone's access and use of the Internet. A systematic and IT-enabled approach to resolve this increasing mess is needed. Added note: There is Paris the city and these is Paris the "departement", there is New York the city and there is New York to state. The problem is resolvable and may require less work than one would expect. Enough said. I am doing some work in this field from an edi and e-commerce perspective as well as that of the environment. If you think this is important, have some ideas, know of other areas where addressing this would be of use, etc. please let me know. Trust this is of some help Regards - Jake Knoppers P.S.I also agree that continent/citynames is not that useful. It neither provides the unambiguity nor uniques required for referencing purposes. A better solution would be along the following lines: 1. Reference the ISO 3166 standard 2. Always start with a Level one country code 3. The a level 2 administrative subdivision code (e.g. state, province, lander, canton, etc) 4. The official name of the place according to the authoritative source, i.e. Wien and not Vienna or Vienne, Köln (or Koln) but not Keulen, Cologne) 5. Optional the associated lat/long coordinate as assigned by the authoritative source. 6. From a human interface needs and localization context, one would be free to provide different linguistic equivalent designations, i.e. "names" While such a solution requires a bit more data, it compensates by being useful to many other application areas as well as facilitating cross-sectorial electronic data interchange. ---------- > From: Markus Kuhn <Markus.Kuhn(a)cl.cam.ac.uk> > To: tz(a)elsie.nci.nih.gov > Subject: Re: Time Zone Names > Date: September 30, 1998 4:25 AM > > Ken Pizzini wrote on 1998-09-30 00:22 UTC: > > Markus Kuhn wrote: > > > As I have pointed out before, I don't like the > > > continent prefix in the Olson/style names, therefore I do not want to > > > make this particular syntax immortal in an ISO standard (I much prefer > > > just ":Paris" over "Europe/Paris"). > > > > Interesting example. Is ``:Paris'' "Paris, France", or "Paris, Texas", > > or perhaps one of the other half-dozen or so cities named Paris? > > Remember that time zone names refer to the most populated area within a > region with common time zone history. This rule should already resolve > practically all ambiguities. If there are really two Paris that are both > candidates for TZ entries as they are both most populated areas in > different time zone regions, then they should get qualifiers added (or > at least all but the largest one should). This way, all those little > Paris clones in the US are not of concern any more, and "Paris" would be > guaranteed to refer to the real big one under the Eiffel's tower. > > To remove any ambiguity, we have the coordinates of the place, and a GUI > TZ selector tools can easily indicate on a map what region we are > talking about. > > > I'm not particularly thrilled with the continent name either, but it > > does serve a purpose. > > But not very well. How many Paris are there in the US alone? > > An ISO 3166-1 country code or where necessary ISO 3166-2 country/region > code for those hypothetical cases where there could occur an ambiguity > would serve this purpose much better. The continent names come from the > file organization of the Olson DB, and this implementation detail should > IMHO not leak through to the name space. That's why I am not particular > happy with seeing iCalendar people making these continent/city names > more permanent by quoting them in their standards. > > If I had to design proper tz names from scratch, they might look more > like > > fr.paris > us.tx.paris > > 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/> > > >

4 3

Re: time.h critique
by Markus Kuhn Oct. 3, 1998

Oct. 3, 1998

Dave Flater wrote on 1998-09-21 18:57 UTC: > > I have read your quite strong critique on the current C/POSIX time API in > > > > http://www.universe.digex.net/~dave/files/xtide-1.6.2.tar.gz > > > > I have recently written a proposal to a modernized time.h in C 9X, which > > you can find on > > > > http://www.cl.cam.ac.uk/~mgk25/c-time/ > > > > When you have some time to read it, I'd be very curious on what you > > think about it and whether this would fulfill your needs if it became > > part of the next C standard. > > I applaud the explicit passing of time zones, the new formats for > strfxtime, the tz_jump function, and of course the fix for the year 2038 > problem. However, I find that there are still some problems in dealing > elegantly with non-continuities. The following changes would make me > happier: > > * Replace the boolean is_dst field of struct_tm with an open-ended > counter compatible with the A/B convention used by strfxtime, but > retain the option of leaving it unspecified. > > * Let xtime_make return an array of zero to N translations of the > requested time instead of either 1 or error. Then when the A/B is > unknown (as it usually is), the application can get a complete answer > the first time instead of having to fumble around when there are > discontinuities. > > * Extend xtime_breakup to use the new A/B field in struct tm. > > * While you're messing with struct tm you can retire some of the other > silly rules like doing years relative to 1900 and the zero-based > numbering of months. I agree fully that your ideas are good suggestions. However: For binary compatibility reasons, we cannot change the size of struct tm. We would have to add a new struct tmx, and double all related functions, which would give the API a quite clumsy appearance. My plan was therefore not to "mess around" with struct tm in any way that might break existing applications. I do not think we gain too much by fixing struct tm: It is hard to imagine that in any time zone a time will repeat itself more than once. Therefore I think it is a reasonable convention that xtime_make interprets tm_isdst as positive for the first interval, zero for the second interval, negative as a reason for signalling an error IF the specified time is ambiguous. If the specified time was not ambiguous in the first place, tm_isdst should be ignored. Surely there are more elegant ways to resolve these ambiguities, but instead of trying to improve struct tm, I think it is much better to make struct tm mostly irrelevant by giving strfxtime direct access to all the available information in the struct xtime and timezone_t objects directly. > Other things that are not "broken" but that you might want to do: > > * Add an explicit interval type, an extended difftime function that > takes two xtimes and returns an interval, and the other obvious > operations. I defined a bunch of operations over timestamps and > intervals in C++ for XTide 2.0 but for C you probably want to > keep it simple. These are indeed rather simple to add, but what would be their semantics in the presence of leap seconds? > * Conversions to and from Julian dates as double precision floating > point numbers would be nice and easy to do. Yes, but this is a single-line function that everyone who needs it can easily add himself. We can add conversions between TIME_UTC and JD or MJD as example notes to the standard, but I would not want to create an inflation of time scales in the basic library API. This sounds more like a function for calendar and astronomy toolkits and not for something a basic time access interface should be concerned with. It is also not clear, what to do in the context of a leap second with the decimal fractions of the day. > Finally, we get down to the real bloat features and things that are out of > scope: > > * I stand by my assertion that the Posix approach to tzstrings is the > Wrong Thing, and that the Right Thing would be to standardize the > tzstrings and functionality of Olson's zoneinfo database. Agreed, and many workstation operating systems will hopefully implement it at this level. But for tiny embedded controller applications we must also allow the entire timezone package to be unimeplemented such that only UTC or monotonic time are available. A requirement for an Olson-like appraoch to implement timezone_t would be more appropriate for a standard like POSIX than for a programming language standard with a much wider scope. For tiny embedded environments (smartcards, etc.) tz_prep should certainly be allowed to always fail. > * You might want to specify an optional function to map a latitude, > longitude, and xtime to the relevant tzstring for that location at > that point in history. Probably nobody will ever implement this, but > if they do, it would be helpful to have a standard interface to it. Well, we are getting far outside of the scope of a general purpose programming language API here. May be, one day we get a nice distributedly administrated database for universal Internet access to up-to-date timezone information (in fact I have some long-term plans along this line), and the access API to this could certainly provide such a functionality such that your GPS-integrated car radio will automatically reset the clock when you cross a border, but let's leave this project until we have fixed the much more fundamental things. Thanks a lot for your comments. I hope you don't mind that I Cc-ed this on the Olson mailing list where xtide has been quoted before as an example application. 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/>

5 4

Re: (SC22WG14.6158) (SC22WG14.6131) (SC22WG14.6130) Summary of problems with draft C9x <time.h>, and a proposed fix
by Canaglobe International Inc. Oct. 2, 1998

Oct. 2, 1998

The dilema noted by Clive Featherstone of a completely satisfactory technical solution versus layering on a still-not-staisfactory solution is, unfortunately, increasingly common in many standardization area particluarly those where there is a substantial sunk investment and user base in legacy systems. I would propose that one approaches the problem by (1) working on the development of a "completely satisfactory technical solution" for ALL the required functionalities and then, and in the context of (1) (2) develop interim solutions, migration strategies/paths, etc. generally as well as required for particular user bases (e.g. the MS-DOS) community In short separate (a) the totality of the needed/desirable from the (b) immediately do-able, need to recognize the reality of sunk investments. This having been recognized, mapped out and accepted, the only remaining contentious question then becomes one of time lines (pardon the pun). Trust that this is of some use - Jake Knoppers

1 0