ISO C strftime() extention for ISO 8601

[Clive D.W. Feather]

My apologies for the extreme delay in addressing this. I have been both busy
and also having trouble locating a copy of 8601 to look at.


"Markus G. Kuhn" <kuhn at cs.purdue.edu> writes
>Thanks a lot for forwarding this interesting working paper.  Please forward
>the following comments to the authors of N733 and whoever else might be
>interested.  If possible, I would like to review the final text of the
>new strftime() definition (will the current draft be on the Web
>somewhere?).

I've taken your comments and will be producing a new paper that addresses
them. No, I don't expect the draft to be on the web any time soon, though my
papers are, at <http://www.gold.net/users/cdwf/c/>.

>  a) The valid range for %V numbers is 01-53.
>  b) %V alone is not sufficient to be able to use the ISO week numbering
>     system. Each week is associated with a year, the year in which the
>     majority of the days of this week fall, and this is not necessarily
>     the year in which all days of the weeks fall.

I can't actually find any text in 8601 that addresses this issue. However,
since what you describe appears to be current practice, I will work on that
basis.

>  c) Existing practice: The Olson tzcode package <ftp://elsie.nci.nih.gov/pub/>
>     contains a widely used strftime() implementation that supports already:
>       %u  ISO 8601 week day number (1 = Monday, 7=Sunday)
>       %V  ISO 8601 week number (01-53)
>       %G  ISO 8601 year of current week, 4-digits
>       %g  ISO 8601 year of current week, 2-digits
>     Unless there is a good rationale for the characters suggested
>     by N733,

N733 used the codes described by our Posix.2 liasion (Keld Simonsen). I will
propose these instead.

>Not directly related to N733, but affecting the same part of the standard,
>I have a number of other suggestions:
>  d) The range for %S and tm_sec is currently defined to be 00-61 to
>     provide for "as many as two leap seconds".  This was based on a
>     serious missunderstanding

Yes: Jutta will tell you that I have been hammering on this for a *long*
time. It *will* get fixed.

>     it becomes very obvious by reading ITU-R Recommendation
>     TF.460-4 (I can send you a copy if you are interested).

Please.

>  e) I wonder whether %W is anywhere used and whether this field could
>     be dropped to simplify implementation and memory cost.

Dropping thing is usually a bad idea. It's unlikely to be a major cost to
implementers, so I'd rather leave it in.

>  f) In the definition of %y and %Y, the first two digits of a four digit
>     year are refered to as the "century", which is problematic,

Noted.

>  g) mktime() is the inverse function of localtime(), but there exists
>     no portable inverse function for gmtime() that converts a struct tm
>     given in UTC into time_t.  This is a serious problem, and the addition
>     of a new function (e.g., mkgmtime() might be a possible name) should
>     be considered seriously.  It is not possible to invert gmtime()
>     in a 100% portable way in an application program,

The type time_t is intended to represent times in a zone-independent manner.
Thus calling localtime() and gmtime() on the same time_t value should give
results that reflect the relationship between UTC and the local zone.

Part of my proposals add extra semantics (including zone knowledge) to
mktime(), so that it will be possible to specify the UTC offset of the time
to be represented.


Antoine adds:
> It should be put in relief that N735 adds:
>   %#W - ISO 8601 week number            ) If %W would be zero, the date is
>   %#y - ISO 8601 week number year % 100 ) treated as belonging to week 53
>   %#Y - ISO 8601 week number year       ) of the previous year

This is unlikely to happen.

-- 
Clive D.W. Feather    | Director of Software Development  | Home email:
Tel: +44 181 371 1138 | Demon Internet Ltd.               | <clive at davros.org>
Fax: +44 181 371 1037 | <clive at demon.net>                 |
Written on my laptop; please observe the Reply-To address |