- tz - lists.iana.org

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