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