From: Jeff Garland (jeff_at_[hidden])
Date: 2008-05-18 14:08:57
Jonathan Biggar wrote:
> 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?
The clocks that return ptime don't allow you to deal with arbitrary timezones
while the local time clocks do. So, for example, suppose you wanted to know
the time in arizona regardless of the computer settings:
//Az is Mountain standard with no dst adjust (hence MST-07)
time_zone_ptr zone( new posix_time_zone("MST-07") );
local_date_time az_time = local_microsec_clock::local_time(zone);
The az_time class now retains the ptr to the zone and hence can provide other
information about the time zone. The timezone settings of the machine don't
matter for this code. For the ones below the machine settings matter.
>> 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.
Not really -- you have to consider the current daylight saving settings as
well, which as I recall you can't really find out. Although, just looking at
it now, maybe you can call asctime to get a tm with that information. But in
any case, what Boost date-time wants to be able to construct a proper timezone
includes the daylight savings transition rules (eg: first sat in April @ 2:00
am transition to dst).
> 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?
Not unambiguously. For example, a machine in Colorado and one in Arizona
measured in January would both return UTC-7 offset with no DST. How would one
know that it's Colorado or Arizona timezone rules?
Of course I could invent or adopt a convention (like setting some environment
variable), but so could you. For example, if administratively you set the TZ
variable to a Posix timezone string on all your machines then you can read the
env variable and use something like the code above to get a fully qualified
timezone for each machine.
I think what's really needed here is an addition to the C/posix api that would
provide the dst rules directly. If that were done and implemented everywhere
this problem would go away.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk