I've just been told by someone from the British mirror of ISO/IEC JTC1/ SC22/WG14 that C9X has now become C99 and that the new ISO C standard (DIS?) has been completed. Did someone here look already into what finally happened to <time.h>? http://anubis.dkuug.dk/JTC1/SC22/WG14/ does not yet seem to have been updated. Markus -- Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/>
Markus Kuhn ha escrit:
I've just been told by someone from the British mirror of ISO/IEC JTC1/ SC22/WG14 that C9X has now become C99 and that the new ISO C standard (DIS?) has been completed.
That is correct. It is even rumored to be published; however, as <URL:http://anubis.dkuug.dk/JTC1/SC22/open/n3050.htm> is not up to date, the notice of publication (that should appear there) is still awaited.
Did someone here look already into what finally happened to <time.h>?
Yes. As you know, the problematic proposed changes were not accepted, and are removed from (what is now) the International Standard. As a result, there are two main differences with respect to C90 (a.k.a. ANSI C 89): - a number of stuff, coming from POSIX, have been added to the specifiers to be used with strftime (and wcsftime); - the default values when in the "C" localization have been fixed (to follow U.S. usage and default practice under Unix). If we except wcsftime, I believe the current tzcode package is conforming with the new standard, but I need to check that carefully (I still have to print my copy of the Standard...) With respect to the last publicly available draft (which should be available at <URL:ftp://dkuug.dk/JTC1/SC22/WG14/www/docs/n869>), the differences are: - the default value when in the "C" localization have been aligned with POSIX; - the 3rd paragraph of mktime have been removed; in N869 it was wrongly requiring mktime to return identical values on subsequent calls; it was only a small point added by the mkxtime stuff, and it stayed unnoticed (mainly my fault) when we dropped the problematic stuff. Antoine
Antoine Leca said:
With respect to the last publicly available draft (which should be available at <URL:ftp://dkuug.dk/JTC1/SC22/WG14/www/docs/n869>), the differences are:
as follows, ignoring grammatical corrections. 7.23.1p1 change "four" to "two". 7.23.1p4: < The tm structure shall contain at least the following < members, in any order. The semantics of the members and < their normal ranges are expressed in the comments. ---
The range and precision of times representable in clock_t and time_t are implementation-defined. The tm structure shall contain at least the following members, in any order. The semantics of the members and their normal ranges are expressed in the comments.
7.23.2.3p3 (mktime) deleted. 7.23.3.5p5 last line, %V is replaced by 01, not by 1. 7.23.3.5p7: < %c equivalent to ``%A %B %d %T %Y''. < %p one of ``am'' or ``pm''. < %x equivalent to ``%A %B %d %Y''. ---
%c equivalent to ``%a %b %e %T %Y''. %p one of ``AM'' or ``PM''. %x equivalent to ``%m/%d/%y''.
-- Clive D.W. Feather | Work: <clive@demon.net> | Tel: +44 20 8371 1138 Internet Expert | Home: <clive@davros.org> | Fax: +44 20 8371 1037 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646
"Clive D.W. Feather" wrote on 1999-11-08 16:06 UTC:
%x equivalent to ``%m/%d/%y''.
Great. The second most horrible numeric date notation in the Western World has now found its way onto holy ISO C paper, in the 13th year (anus horribilis? :) after the publication of ISO 8601. (The most horrible one comes of course also from our American friends: Copyright years given in roman numerals in the trailers of Hollywood movies.) Markus -- Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/>
Markus Kuhn said:
"Clive D.W. Feather" wrote on 1999-11-08 16:06 UTC:
%x equivalent to ``%m/%d/%y''.
Great. The second most horrible numeric date notation in the Western World has now found its way onto holy ISO C paper
Yup. All in the name of WG15 (*spit*) compatibility. [In particular, ou WG14 liason appeared to miss this issue for N years while wittering on about isblank() and suchlike.] -- Clive D.W. Feather | Work: <clive@demon.net> | Tel: +44 20 8371 1138 Internet Expert | Home: <clive@davros.org> | Fax: +44 20 8371 1037 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646
Date: Mon, 8 Nov 1999 16:06:01 +0000 From: "Clive D.W. Feather" <clive@demon.net>
%c equivalent to ``%a %b %e %T %Y''. %p one of ``AM'' or ``PM''. %x equivalent to ``%m/%d/%y''.
Thanks for the heads-up. This means that the tz strftime needs to be fixed to conform to C99. Here's a proposed patch. =================================================================== RCS file: RCS/strftime.c,v retrieving revision 1996.12 retrieving revision 1996.12.0.1 diff -pu -r1996.12 -r1996.12.0.1 --- strftime.c 1996/09/08 20:14:01 1996.12 +++ strftime.c 1999/11/08 18:39:37 1996.12.0.1 @@ -80,24 +80,21 @@ static const struct lc_time_T C_time_loc /* ** x_fmt - ** Since the C language standard calls for - ** "date, using locale's date format," anything goes. + ** C99 requires this format. ** Using just numbers (as here) makes Quakers happier; ** it's also compatible with SVR4. - ** - ** XXX--might it be better to use the year-2000 friendly - ** %Y-%m-%d - ** here? */ "%m/%d/%y", /* ** c_fmt + ** C99 requires this format. + ** Previously this code used "%D %X", but we now conform to C99. ** Note that - ** "%a %b %d %H:%M:%S %Y" + ** "%a %b %d %H:%M:%S %Y" ** is used by Solaris 2.3. */ - "%D %X", /* %m/%d/%y %H:%M:%S */ + "%a %b %e %T %Y", /* am */ "AM",
participants (4)
-
Antoine Leca -
Clive D.W. Feather -
Markus Kuhn -
Paul Eggert