Re: [boost] [date_time] Time zone improvements

Subject: Re: [boost] [date_time] Time zone improvements
From: Rutger ter Borg (rutger_at_[hidden])
Date: 2008-12-01 14:22:55

Jeff Garland wrote:
> 
> This thread is in slow motion...but keeping it going...

Yes. 

> Ok, again it would be wonderful if this could also be deployed to a
> properly configure Windows system -- preferably without changing the
> string.

My examples are using absolute path names. It should also work for relative
path names, so we could say posix_time_zone( ":America/New_York" ), or
posix_time_zone( ":localtime" ) for the system's local time zone (which is
just a symlink to the local time zone). 

What it would require is a default path for the zoneinfo files, e.g., under
most posix systems these zone definitions are in /usr/share/zoneinfo/. For
Windows-based systems, we would have to figure out a reasonable and/or 
default. 

> Look carefully at the abstract time zone.  It's designed so that when you
> ask for the local_start_time and the local_end_time for dst you need to
> provide the year as a parameter so that subclasses can provide the
> historic conversions -- so it looks like this:
> 
>    time_zone_base tz = ...
>    ptime t = tz.dst_local_start_time(2008);
> 
> But, it's possible that to fully support support Olsen you'll need
> dst_offset
> and maybe some others to be expanded to support a year parameter as well. 
> In any case I think we should be able to do that in a backward compatible
> fashion.

That is under the assumption that a year has exactly two transition
points -- which is false for a number of historic cases. This sometimes
occurred when a locality switched time zone rules. Take the example of
Europe/Amsterdam, where there have been three transitions in 1937, see
below.

$ date -d "19370201"
Mon Feb  1 00:00:00 AMT 1937
$ date -d "19370801"
Sun Aug  1 00:00:00 NEST 1937
$ date -d "19371101"
Mon Nov  1 00:00:00 NET 1937

> At first blush, I'd like to make as few changes to the abstract timezone
> as possible and would prefer to simply add a new subclass, but I'll keep
> an open mind as we work thru the details.

Here's where the more difficult part comes, I think we have two options: 

 * We modify the abstract time zone in such way that it has a superset of
its current capabilities, covering both POSIX timezone variant
requirements.

 * We do a run-time selection of timezone base, selecting one of the
implementations of both POSIX-variants.

I am probably in favour of the first option, given that we don't change the
posix_time_zone interface itself, and most work will be under the hood for
hopefully a larger part of the current userbase. 

Cheers,

Rutger