On Thursday, June 7 2001, "Joseph S. Myers" wrote to "Jonathan Lennox, <tz@elsie.nci.nih.gov>" saying:
Have you looked at Markus Kuhn's proposal at
http://www.cl.cam.ac.uk/~mgk25/c-time/
and the other ones linked to from there?
No, I hadn't. It's interesting -- he has some of the same ideas I had, but trying to solve some problems that are rather larger in scope. I was trying to solve a much smaller problem -- making the minimal changes to existing functions needed in order to get re-entrant timezone support.
My recommendations:
* Design the proposal as an amendment for ISO C rather than POSIX.
Wouldn't it need to be an amendment to both? I don't have either specification handy, but I was under the impression that the TZ environment variable, and tzset(), were POSIX.
* Don't touch how timestamps are represented (any interface can be adapted to use any time_t replacement that gets agreed).
Agreed.
* Provide a struct tm replacement with (a) subsecond resolution and (b) a proper field indicating which repetition of a repeated timestamp is referred to (A/B in German time notation), rather than the inadequate indication of whether the time is in daylight savings.
I think this is orthogonal to what I'm looking at. I agree it's a good idea in principle, but I don't think I have the expertise to do it in practice.
* Provide four conversion functions: between time_t and broken down times, in either direction, and equivalents of strftime and wcsftime. Don't duplicate other functions such as asctime that can easily be replicated.
Fair enough. Also a good point about the wide versions. What's your thought on strptime_z()? (And should there be a wcsptime_z()?)
* Use an C99 snprintf-style return value (return the length of buffer required if the buffer isn't long enough) rather than what strftime currently does (return 0 if the buffer isn't long enough).
Useful enough, I suppose, but is it worth the compatibility break with strftime()?
* Provide specified timezone names for both the user's local timezone and the system's local timezone.
I don't think ISO C distinguishes between these concepts, and for POSIX, getenv("TZ") should be sufficient for the former, no? I defined the NULL string as representing the latter. -- Jonathan Lennox lennox@cs.columbia.edu