From: Jonathan Biggar (jon_at_[hidden])
Date: 2008-05-15 17:16:49
Jeff Garland wrote:
> Jonathan Biggar wrote:
>> I found getting either of thse two bits of information to be much harder
>> than it ought to be:
>> 1. The default time zone for the program.
> Right -- there's not really a portable way to do this unfortunately. So if
> you know a way I'm all ears.
>> 2. The time zone offset for the local_date_time clocks.
> Not sure I understand. You have to pass a tz to the clock as I recall, so how
> does this matter?
Ok, then maybe I'm confused. What's the difference between these two
functions that return ptime?
> ptime second_clock::local_time()
> Get the local time, second level resolution, based on the time zone settings of the computer.
> ptime second_clock::universal_time()
> Get the UTC time.
Isn't second_clock::local_time() - second_clock::universal_time()
theoretically the timezone offset? I'd do that, but there's a chance
that the second_clock ticks between the two calls.
Can't this be calculated by calling localtime() and gmtime() on the same
time_t value and doing the right math? Seems straightforward to me, and
a nice addition to the library.
And once we have the local timezone offset, it shouldn't be too hard to
search the timezone database to fine the zone(s) that match, right?
-- Jon Biggar Floorboard Software jon_at_[hidden] jon_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk