ISO 14652 draft on POSIX date/time/tz
Those of you interested in upcoming ISO standards related to date/time/ timezone APIs for POSIX systems should have a look at http://www.cl.cam.ac.uk/~mgk25/volatile/ISO-14652.pdf especially section 4.7 (8 pages). This is the usual holy ISO top secret draft stuff for the enlightened inner circles only, so don't tell anyone where you found it. I feel that some of the things it introduces (e.g., the ISO 8601 B.C. notation) might need a bit more scrutinizing and alignment with ISO C9x strftime(), but see for yourself. Editor of this seems to be Keld Simonsen <keld@dkuug.dk> and responsible is <http://anubis.dkuug.dk/JTC1/SC22/WG20/> where comments should be directed to have impact. Markus -- Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/>
On Sun, 27 Jun 1999, Markus Kuhn wrote:
Those of you interested in upcoming ISO standards related to date/time/ timezone APIs for POSIX systems should have a look at
The first thing I wonder about this is what implementation experience there is of including timezone specifications in the locale specification as this does? After all, when C9X revisions were being discussed it was insisted that any significant new features should be based on previous implementation experience! However, more generally there seem to be several problems with the specification in this area; it doesn't define what a timezone is, and states both that each string defines a timezone and that standard and summer time are separate time zones (and if `time zone' and `timezone' are distinguished, this is a very bad idea, though it has precedence in POSIX.2 drafts - see E.2.2.2 on the former use of `file name' and `filename'); it is unclear about why you might define multiple timezones within a locale, whether they represent different geographical areas or variations in historical behaviour; it does not improve on POSIX.1 by allowing for `Sunday after the third Saturday'; and it is very unclear how to specify single and double summer time in a single year. Also the use of what would seem to be a US date format for dates in the rationale, rather than an ISO 8601 format, betrays at the very least bad editing. The example for Denmark, through not attempting to specify historical behaviour, fails to clarify these matters at all (and appears to be actually wrong in (not) specifying the times of changes between standard and summer time, since the defaults do not correspond to the EU rules). -- Joseph S. Myers jsm28@cam.ac.uk
participants (2)
-
Joseph S. Myers -
Markus Kuhn