From: Jonathan Lennox <lennox@cs.columbia.edu> Date: Thu, 7 Jun 2001 12:09:33 -0400 (EDT)
* Are people interested in this? * Would people be interested in seeing the resulting code? * Would people be interested in helping write the code? * Would the resulting code (assuming it's written sensibly) be acceptable/appropriate for incorporation into tzcode?
Yes, several people have proposed something along those lines. (I'm one of them -- see <http://www.twinsun.com/tz/timeapi.html>.) However, nobody has gotten anything running yet. Part of the problem with many of the proposals (mine included) is that they're perhaps too ambitious. There are a lot of problems with the existing interfaces, and it's a pain to solve them all at once.
* Do people think that my proposal is a sensible API?
Here are some thoughts: * Is this spec compatible with Drepper's proposal? This is a relevant issue, since time zone names ought to be part of the locale. For example, where you say "EDT", a French Canadian would say "HAE". Thus, for example, for full generality it seems to me that localtime_z would need to have a locale parameter or have access to the locale somehow. Admittedly the current time zone database does not support any locale other than English, but we've seen proposals for fixing this and it will probably happen some day. * Conversely, if you merge Drepper's work with your proposal, then 'struct tz' should be part of his locale object, so that there is no need for a separate 'struct tz', or a separate 'localtime_z', etc. Perhaps this is too drastic (as you may not want to assume Drepper's approach), but treating TZ like we treat LC_CTYPE etc. would have real advantages if we were starting from green fields. * I see no reason for struct tz to make tz_name visible. If a user wants the time zone name, he can use strftime_z with the "%Z" format. Many time zones have more than two names, so it's incorrect for tz_name to have just two elements anyway. * I would drop 'tzuse', or at least make it optional and dependent on support for POSIX threads. If you drop it, you don't have to worry about threads at all; you'll simply have thread-safe functions. It's not worth the hassle of interacting with all the different thread implementations out there. * Frankly, I don't know how POSIX functions like localtime_r are supposed to interact with setting the TZ variable. It seems to me that the POSIX spec is unclear here. This murk is not your fault, but it seems to me that if you want to address the thread problem that this issue should be made crystal clear in any thread-safe spec. * 'strptime_z' should be marked as being POSIX-only; it needn't be available on ISO-C-only systems. * What is the use of 'duptz'? Can you give an example that cannot easily be expressed without 'duptz'? * A nit: you mention "GMT0", but the latest POSIX draft says that "date -u" acts as if TZ is either "UTC0" or "GMT0", with "UTC0" preferred.
Date: Thu, 7 Jun 2001 17:30:58 +0100 (BST) From: "Joseph S. Myers" <jsm28@cam.ac.uk>
* Don't touch how timestamps are represented (any interface can be adapted to use any time_t replacement that gets agreed).
Presumably if we have an xtime_t, then the xtime_t functions will address all the issues Lennox raises, because they'll have merged or subsumed his ideas.
* 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. * 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. * 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).
These changes all sound reasonable to me -- though they make the proposal more ambitious. If we go down this route, though, we should definitely look at Kuhn's and my proposals (both of which are too ambitious, in my opinion). I could try to merge the three, or perhaps you'd like to take a crack at it.
* Provide specified timezone names for both the user's local timezone and the system's local timezone.
Doesn't his proposed API already do this, with newtz(getenv("TZ")) and newtz(NULL)?