
I just wanted to start writing a ISO 8601 subset -> time_t conversion routine, but to my great disappointment I discovered that ISO C does not seem to allow portable conversion of a broken-down time into time_t. In other words, while mktime() is the inverse function to localtime(), there exists no mkgmtime() that is the inverse function to gmtime(). I knew that the C standard library time API is a strange design, but I had no idea that it was *that* bad. The only practical way to get from a broken-down UTC time to time_t seems to be to assume that we are on a POSIX system where the time_t representation is exactly specified. Or did I miss something? In case someone of you is in contact with the folks revising ISO C, I have now a whole list of things that should be fixed in time.h: - add inverse function for gmtime() (mkutime() or mkgmtime()) - add to strftime() conversion specifiers for ISO 8601 week-of-year and year-of-week. - remove the second leap second 61 mentioned in the footnote (contradicts to UTC definition) Instead of adding an inverse function for gmtime, one could also extend struct tm by a new field tm_offset, which is in seconds the difference between the time in the struct tm and the corresponding universal time (in my opinion a much cleaner solution than the tm_isdst hack). But I guess, this might break existing code that does not initialize tm_offset ... Having a tm_offset in struct tm would however still be a good idea as this would allow to implement in strftime() conversion specifiers for the time zone offset (much more interesting than the time zone name). Markus -- Markus G. Kuhn, Computer Science grad student, Purdue University, Indiana, USA -- email: kuhn@cs.purdue.edu

Date: Mon, 20 Jan 1997 18:05:08 -0500 From: kuhn@cs.purdue.edu ("Markus G. Kuhn") In other words, while mktime() is the inverse function to localtime(), there exists no mkgmtime() that is the inverse function to gmtime(). I believe there was debate about this when C was first being standardized, and the tz package's timegm and timeoff functions reflect some of the proposals that were not adopted in the final standard. The GNU C library also has timegm. I knew that the C standard library time API is a strange design, but I had no idea that it was *that* bad. It's pretty crufty, all right. For example, the library should be reentrant (including locale info), but for various historical reasons it isn't. Perhaps someone with some spare time could propose and implement a better interface. The only practical way to get from a broken-down UTC time to time_t seems to be to assume that we are on a POSIX system where the time_t representation is exactly specified. That's pretty much true, though you can relax some of Posix's assumptions. You don't need to know whether leap seconds are supported (as they are on some quasi-Posix systems), since you can detect them as they arise. Also, you don't need to know the epoch since you can compute it at runtime. If you're interested in writing an ISO 8601 date parser, I suggest you look at RCS 5.7's partime and maketime modules. I think they parse all the ISO 8601 date formats, except they ignore fractional seconds. You can rip out the support for RFC 822 dates if you like (;-). In case someone of you is in contact with the folks revising ISO C, Nobody is right now as far as I know. See <URL:ftp://ftp.dmk.com/DMK/sc22wg14/c9x/Revision-guidelines/charter.txt.gz> for how to submit a proposed change. I have now a whole list of things that should be fixed in time.h: - add inverse function for gmtime() (mkutime() or mkgmtime()) timegm should do it. - add to strftime() conversion specifiers for ISO 8601 week-of-year and year-of-week. tz, glibc 2, and the Robbins strftime support %V and %G for these two values; they also support %g for the last 2 digits of %G. Instead of adding an inverse function for gmtime, one could also extend struct tm by a new field tm_offset, which is in seconds the difference between the time in the struct tm and the corresponding universal time (in my opinion a much cleaner solution than the tm_isdst hack). Existing practice is to call this field `tm_gmtoff'. Also, it would be helpful to be able to pass a time zone specification to the time conversion functions, so that one could ask ``please convert this as if we were in New York City''. Also, there should be fully reentrant versions of the functions (including reentrant support for locales). This is needed for applications needing access to multiple locales and timezones.

On Mon, 20 Jan 1997, Markus G. Kuhn wrote:
I just wanted to start writing a ISO 8601 subset -> time_t conversion routine, but to my great disappointment I discovered that ISO C does not seem to allow portable conversion of a broken-down time into time_t.
In other words, while mktime() is the inverse function to localtime(), there exists no mkgmtime() that is the inverse function to gmtime(). I knew that the C standard library time API is a strange design, but I had no idea that it was *that* bad.
The only practical way to get from a broken-down UTC time to time_t seems to be to assume that we are on a POSIX system where the time_t representation is exactly specified.
Or did I miss something?
You can do a binary search of the time_t space using the gmtime() function. This does require the assumption that time_t is an integral type, but works well. I have some source to do it, but it has two copyrights on it. It'd be nice to have source in the date-time document which was unencumbered...
participants (3)
-
Chris Newman
-
kuhn@cs.purdue.edu
-
Paul Eggert