A discussion on POSIX on new timezone related C APIs
http://austingroupbugs.net/view.php?id=1005 The proposals seem to be: 1. Something involving integrating timezone information into locale_t 2. Something along the lines of NetBSD's _z/_rz functions The fact that no-one seems to have a reference C implementation of localizing time zone names/abbreviations also came up. I don't know how open they are to outsiders sticking their noses into the process though, just thought some people here might be interested. Also proposed is the addition of "tm_nsec" to struct tm, and the new APIs in one of the proposals use a struct timespec rather than time_t.
On Nov 12, 2015, at 11:33 AM, Random832 <random832@fastmail.com> wrote:
http://austingroupbugs.net/view.php?id=1005
The proposals seem to be: 1. Something involving integrating timezone information into locale_t 2. Something along the lines of NetBSD's _z/_rz functions
The fact that no-one seems to have a reference C implementation of localizing time zone names/abbreviations also came up.
I don't know how open they are to outsiders sticking their noses into the process though, just thought some people here might be interested.
I'm not sure what constitutes an "outsider"; I and, I think, kre were involved with POSIX at some point, but, for me, that was decades ago. They sound pretty open: https://www.opengroup.org/austin/ I've signed up for an account there and have made some comments, as has kre.
On Nov 12, 3:05pm, guy@alum.mit.edu (Guy Harris) wrote: -- Subject: Re: [tz] A discussion on POSIX on new timezone related C APIs If we are going to mandate tm_zone in struct tm, we might as well resolve the issue of where/how it is allocated and who free's it, or do we give it a fixed buffer. Right now, there is no easy way to return a name, unless we are returning the name that is in timezone_t, and even that is iffy because then the lifetime of tm->tm_zone is connected with the timezone_t one... christos
On Nov 12, 2015, at 3:17 PM, Christos Zoulas <christos@zoulas.com> wrote:
If we are going to mandate tm_zone in struct tm, we might as well resolve the issue of where/how it is allocated and who free's it, or do we give it a fixed buffer. Right now, there is no easy way to return a name, unless we are returning the name that is in timezone_t, and even that is iffy because then the lifetime of tm->tm_zone is connected with the timezone_t one...
Yeah, I think somebody mentioned the lifetime question in one of the comments on that issue. :-)
Date: Thu, 12 Nov 2015 15:05:50 -0800 From: Guy Harris <guy@alum.mit.edu> Message-ID: <8DD4DDDC-DFE0-487B-8C16-AAFBBAA69D57@alum.mit.edu> | I'm not sure what constitutes an "outsider"; I and, I think, | kre were involved with POSIX at some point, me, not really, but yes, it is not difficult to get involved. I was fascinated to see the proposal for a localtime() lookalike that uses timespec and has a sub-second abilities .. I had been contemplating creating exactly that (in a thread safe way of course) over the past few weeks (inspired by working on some time parsing code that deals with times with factional seconds, and does nothing but ignore the fraction, given there's no place in a struct tm to put it). I don't think I'd have suggested modifying struct tm though, I would have just invented a whole new (quite similar...) struct - code to use the new function, after all, user code would need to be modified in any case, doing it this way keeps binary compat with existing users of struct tm, which making the struct bigger does not. kre
participants (4)
-
christos＠zoulas.com -
Guy Harris -
Random832 -
Robert Elz