On Mon, 22 Aug 2005 11:46:34 +1000, Brendon Costa wrote
Thanks for the reply. See below for notes...
.. snip details...
Here is an excerpt from the localtime man page that is relevant:
...snip details
stored; also, localtime_r() does not imply initialization of the local time conversion information; the application may need to do so by calling tzset(3).
This seems to be a BSD unique rule -- my Linux manpage says the opposite :-(
I am not sure if calling tzset() is a patch that should be made to the boost date time library (Don't know what effects it may have on other systems) or if it is something that I should request for the NetBSD maintainers (I assume there is a good reason localtime_r() does not call tzset() itself, as it is explicitly stated in the NetBSD man pages that the user may need to do so).
Well, there may be some reason, but I'd quibble with it being 'good'. Somehow Linux managed to maintain the same behavior as localtime. So it seems like it is doable. I see 3 options going forward (or while we wait for BSD to change this): 1) restore the 1.32 behavior by disabling _r functions 2) make the user call tzset once before calling date-time clock functions 3) have date-time call tzset once for BSD only You can do 1 and 2 yourself -- 3 can't happen till the next release...
BTW, in 1.33 there's better support for local time than the old c_local_adjustor.
Is there any way of loading the systems current timezone from the database? I dont want to have to require the user to specify the timezone for each application as a part of its configuration, and it can't be hardcoded as the application can be run in various different timezones. I had a brief look through the new timezone stuff and couldnt find anything for doing this (Though sometimes I am quite blind to what is right in front of me...)
No, unfortunately there isn't that I know (if someone knows a solution, I'd love to hear it). The main problem is that system API's seem like they have about half the information to really specify a timezone. However, you do have some options. If you can force the installation of a timezone environment string holding a posix time zone specification then you can read it and construct a posix_time_zone. On some systems that might actually work out of the box. Or you could install a config file with the posix string in it.
Thanks again for the reply. By the way the date time library is very useful! Thanks for all the hard work that has been put into it.
You're welcome :-) Jeff