On Nov 2, 2011, at 10:12 AM, Bennett Todd wrote:

It'd surely be nice if this reorg could be propagated to tzcode, in C, ultimately to wend its way into libc everywhere; forking or independently reimplementing tzcode carries a maintenance cost, as the tzdata format isn't quite completely set in stone yet, and as sufficiently clever legislators cook up sufficiently brilliant schemes to "save daylight", it's possible tzdata format and tzcode may have to co-evolve again.

Any folks on this list have opinions about how the tzset/localtime api should best evolve?

I think that, all other things being equal, if it's already evolved on at least one UN*X, it should evolve in the same direction, as tzcode is used as the basis of many libc implementations (*BSD, Mac OS X, maybe Solaris if they're keeping up with changes). I.e., I'd go with Christos Zoulas' APIs unless either 1) some other UN*X has a different API, at which point the multiple APIs should be investigated or 2) there's a significant problem with them.

From a quick look at the NetBSD APIs, we have:

timezone_t tzalloc(const char *name); takes a time zone name as an argument, and returns NULL on failure to load that zone and a timezone_t (an opaque handle, implemented as a pointer to an opaque structure) on success void tzfree(const timezone_t sp); releases the result of tzalloc() struct tm *localtime_rz(const timezone_t sp, const time_t * __restrict timep, struct tm *tmp); given a timezone_t and a time_t, fills in a struct tm - presumably returns the struct tm * passed to it time_t mktime_z(const timezone_t sp, struct tm *tmp); given a timezone_t and a struct tm, returns a time_t size_t strftime_z(const timezone_t sp, char * const s, const size_t maxsize, const char * const format, const struct tm * const t); given a timezone_t, a struct tm, and a format, fills in a string with the time formatted according to the string Presumably the timezone_t is needed for the time zone name, as 1) even if NetBSD might have tm_gmtoff and tm_zone fields in struct tm, not all systems will necessarily have it and 2) even if it does, the problem of "what happens if tm_zone points to something in the timezone state and that gets freed before a reference is made to the struct tm?" remains. I think having APIs that explicitly take a loaded time zone as an argument is something we should do, as thread safety isn't the only issue; there are reasons to have more than one time zone used for time conversions within a given single thread of control.

Or, if going varargs is tasteless, maybe rename localtime_rz tzconvert, and implementing localtime as a trivial wrapper?

<<On Wed, 2 Nov 2011 15:34:49 -0400, Bennett Todd <bet@rahul.net> said:

That sounds all superb, and excellent. The one question I'd ask is, would it be practical and reasonable to lose the _z and _rz suffixes, and make the timezone arg an optional extra arg to localtime/mktine, with varargs?

The C standard does not allow this. There are no "optional extra args" in C. (A variadic function must have enough information from mandatory arguments to determine exactly how many arguments there are.) Besides which, the prototype of the functions from the C standard is fixed by the standard. -GAWollman

Thanks for the additional info. I Hadn't realized that random _x suffixes had been blessed into standards, I'd thought they were platform-specific kluges. That said, maybe it's time to add not only tzalloc and tzfree, but also tzconvert, then implement locwltime_? and kin, as well as tzset and localtime, in terms of primitives that look better, particularly in documentation?

Am 02.11.2011 21:20, schrieb Alan Barrett:

On Wed, 02 Nov 2011, Bennett Todd wrote:

...

That sounds all superb, and excellent. The one question I'd ask is, would it be practical and reasonable to lose the _z and _rz suffixes, and make the timezone arg an optional extra arg to localtime/mktine, with varargs?

There's a long history of using "_r" a suffix for "re-entrant" or "thread safe" versions of functions. Using "_z" for functions that take an explicit timezone argument is new, but seems to fit the established pattern.

varargs functions need a way of knowing whether or not more arguments are present. How would you do that?

--apb (Alan Barrett)

glibc already has localtime_r() also the other functions are covered. NTL it would be nice to have a reference implemtation, here also. Since POSIX has defined an API (http://pubs.opengroup.org/onlinepubs/9699919799/functions/localtime.html). The party is over. What still is needed are localtime zones. re, wh

On Nov 2, 2011, at 3:49 PM, Christos Zoulas wrote:

On Nov 2, 12:08pm, guy@alum.mit.edu (Guy Harris) wrote:

| Presumably the timezone_t is needed for the time zone name, as

No, it is the loaded tzstate.

The timezone_t is a pointer to the loaded tzstate, is it not? strftime() only needs time zone information for the time zone name and offset, unless I'm missing something.

| I think having APIs that explicitly take a loaded time zone as an argument is something we should do, as thread safety isn't the only issue; there are reasons to have more than one time zone used for time conversions within a given single thread of control.

That is what has been done;

It's what has been done in NetBSD; it's not what has been done, yet, in the tzcode.

why do you think otherwise?

Because *nothing* has been done yet in the tzcode, which is what we're discussing. I'm trying to indicate that "make the tzstate per-thread data" may solve the thread-safety problem but won't solve other problems, so I'd vote for APIs that take a loaded time zone as an argument, such as the NetBSD ones, rather than just making the tzstate per-thread data.

<<On Wed, 2 Nov 2011 16:45:00 -0400, Mike Frysinger <vapier@gentoo.org> said:

POSIX already covers things like localtime(). if people want to extend the time API that is part of the C library, then that discussion should happen on the POSIX mailing lists.

Actually, it's generally the preference of the Austin Group to standardize existing practice, so the right thing to do is to add these extensions to tzcode, and then allow the downstream consumers to add them to their C libraries as they see fit. Then a proposal can be written to include them in POSIX (or in the next revision of C, which is a different standards committee, since they are actually C standard library functions). I would very much like to see this happen. The only quibble I would make with Christos's proposed API is that, because C does not have incomplete typedefs, a new foo_t type should not be introduced. Using such typedefs creates undesirable ordering dependencies between headers (not a problem for the Implementation but definitely a problem for applications if they want to minimize namespace pollution). Using an incomplete structure type has all the benefits of a typedef and none of the drawbacks. If the proposal is adopted by either C or POSIX, they will ignore the drawbacks and create a new _t type anyway, but since they have joint custody of the "_t" namespace, they can at least guarantee that it's defined in an official system header as well. -GAWollman

Garrett Wollman said:

I would very much like to see this happen. The only quibble I would make with Christos's proposed API is that, because C does not have incomplete typedefs,

Huh? Of course C has incomplete typedefs. typedef struct fred jim; struct fred { int sheila; }; is perfectly legal code.

Using such typedefs creates undesirable ordering dependencies between headers (not a problem for the Implementation but definitely a problem for applications if they want to minimize namespace pollution).

There are various ways to fix this. Note that C already requires that all standard headers can be included in any order even when there are dependencies between them. (I haven't seen the proposal, so I may be misunderstanding what you're getting at. If so, please explain.) -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646