[tz] Thread-safe localtime(3) (was Re: Reading binary files)

[Christos Zoulas]

On Nov 2, 12:08pm, guy at alum.mit.edu (Guy Harris) wrote:
-- Subject: Re: [tz] Thread-safe localtime(3) (was Re:  Reading binary files)

| >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

No, it is the loaded tzstate. 

| 	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.

You document that you cannot free the timezone_t if you want to keep using
the referene.

| 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; why do you think otherwise?

christos