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

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.

Jeff