- tz - lists.iana.org

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