|
Boost Users : |
From: Jeff Garland (jeff_at_[hidden])
Date: 2005-08-21 22:01:24
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
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net