Re: [boost] [date_time] Deficiencies in the interface

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]