[date_time] Time zone improvements

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

[date_time] Time zone improvements

Rutger ter Borg-2


Dear Boost.Date_Time developers,

Being a heavy user of Boost's Date_Time library, I think it is very useful.
However, I think one area could use improvement: its time zone handling.

I would like to bring the full Olson tz database [1] to Boost.Date_Time.
This offers a very high-quality, and, on package-managed-UNIX-systems, a
maintainance-free solution to a time zone database. I have written a modern
C++ implementation for reading zic-compiled binary zoneinfo-files.

At the moment, Boost.Date_Time is not able to represent time zones that
have DST offsets and/or zone abbreviations depending on (or, changing over)
time. I.e., if a country or locality changes its time zone definitions.
E.g., a system that is in "Europe/Amsterdam" has changing DST offset and
time zone
abbreviation, which depend on time

$ date -d "2008-10-10 20:00:00Z"
Fri Oct 10 22:00:00 CEST 2008
$ date -d "1930-10-10 20:00:00Z"
Fri Oct 10 20:19:32 AMT 1930

I would like to propose changes that enables Boost.Date_Time to represent
time zone definitions that change over time. The semantics will remain
similar to the current version,

boost::shared_ptr< time_zone >  my_zone( "Europe/Amsterdam" );
local_date_time some_time( pt, my_zone );

some_time.utc_time();    // 2008-Oct-10 20:00:00
some_time.local_time();  // 2008-Oct-10 22:00:00
some_time.is_dst();      // true
some_time.zone_abbrev(); // "CEST"
some_time.dst_offset();  // 02:00:00

in addition, the abstract Time Zone interface and supported accessors will
have to undergo a change. Although the desired result may be achieved in
multiple ways, I think the time zone base could support accessors like
from_utc( ptime const& p) and from_local(...) methods, perhaps returning a
(pointer to a) ttinfo tuple,

// UTC offset, is_dst, abbreviation
typedef boost::tuple< time_duration_type, bool_type, string_type > ttinfo;

and/or a special type in case the conversion is ambigious. When using the
Olsen data base, this structure could be looked up through from_utc using
std::lower_bound on a std::map or a ptr_map of transition points.

I see a local_time_iterator is absent from the library, which I would like
to add as well.

By way of this email I would like to ask whether there is interest the
proposed improvement. If so, please let me know, so we can work on the
details.

Kind regards,

Rutger ter Borg


[1] Sources for Time Zone and Daylight Saving Time Data,
http://www.twinsun.com/tz/tz-link.htm


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [date_time] Time zone improvements

Mika Heiskanen
Rutger ter Borg wrote:

> I would like to propose changes that enables Boost.Date_Time to represent
> time zone definitions that change over time. The semantics will remain
> similar to the current version,
[snip]
> By way of this email I would like to ask whether there is interest the
> proposed improvement. If so, please let me know, so we can work on the
> details.

Yes, there is interest. Timezone descriptions do actually change every now
and then, only a couple days ago I saw an announcement of changes in the
Brazilian and Argentinian DST rules.

--> Mika Heiskanen

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [date_time] Time zone improvements

Jeff Garland-2
In reply to this post by Rutger ter Borg-2
On Mon, Oct 20, 2008 at 6:08 AM, Rutger ter Borg <[hidden email]> wrote:

>
>
> Dear Boost.Date_Time developers,
>

Hi Rutger :-)


> Being a heavy user of Boost's Date_Time library, I think it is very useful.
> However, I think one area could use improvement: its time zone handling.
>
> I would like to bring the full Olson tz database [1] to Boost.Date_Time.
> This offers a very high-quality, and, on package-managed-UNIX-systems, a
> maintainance-free solution to a time zone database. I have written a modern
> C++ implementation for reading zic-compiled binary zoneinfo-files.
>

Very cool :-) One question -- is there a portable solution where a user
could deploy a files onto a Windows system or is it a Unix only solution?
I'm fine with incorporating a *nix only solution because what your
suggesting will be a nice solution for *nix platforms, but it will need to
be clear that it's not portable.


> At the moment, Boost.Date_Time is not able to represent time zones that
> have DST offsets and/or zone abbreviations depending on (or, changing over)
> time. I.e., if a country or locality changes its time zone definitions.
> E.g., a system that is in "Europe/Amsterdam" has changing DST offset and
> time zone
> abbreviation, which depend on time
>
> $ date -d "2008-10-10 20:00:00Z"
> Fri Oct 10 22:00:00 CEST 2008
> $ date -d "1930-10-10 20:00:00Z"
> Fri Oct 10 20:19:32 AMT 1930
>

Actually, I believe the abstract timezone is able to support this, but there
isn't a concrete implementation.  It would be great to have the concrete
implementation to prove out the abstraction (obviously from the text below
you think there needs to be changes).


>
> I would like to propose changes that enables Boost.Date_Time to represent
> time zone definitions that change over time. The semantics will remain
> similar to the current version,
>
> boost::shared_ptr< time_zone >  my_zone( "Europe/Amsterdam" );
> local_date_time some_time( pt, my_zone );
>
> some_time.utc_time();    // 2008-Oct-10 20:00:00
> some_time.local_time();  // 2008-Oct-10 22:00:00
> some_time.is_dst();      // true
> some_time.zone_abbrev(); // "CEST"
> some_time.dst_offset();  // 02:00:00
>
> in addition, the abstract Time Zone interface and supported accessors will
> have to undergo a change. Although the desired result may be achieved in
> multiple ways, I think the time zone base could support accessors like
> from_utc( ptime const& p) and from_local(...) methods, perhaps returning a
> (pointer to a) ttinfo tuple,
>

Ok.


>
> // UTC offset, is_dst, abbreviation
> typedef boost::tuple< time_duration_type, bool_type, string_type > ttinfo;
>
> and/or a special type in case the conversion is ambigious. When using the
> Olsen data base, this structure could be looked up through from_utc using
> std::lower_bound on a std::map or a ptr_map of transition points.
>
> I see a local_time_iterator is absent from the library, which I would like
> to add as well.
>

Yep.


>
> By way of this email I would like to ask whether there is interest the
> proposed improvement. If so, please let me know, so we can work on the
> details.
>

As the primary maintainer of Boost date-time I can say with certainty that
there is interest in this functionality -- it's long been on my todo list
and I haven't had time to get to it.  You can email me privately and we can
discuss all the details of how to get your code incorporated.

Thx!

Jeff
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [date_time] Time zone improvements

Rutger ter Borg-2
In reply to this post by Rutger ter Borg-2

Jeff Garland wrote:

> Very cool :-) One question -- is there a portable solution where a user
> could deploy a files onto a Windows system or is it a Unix only solution?
> I'm fine with incorporating a *nix only solution because what your
> suggesting will be a nice solution for *nix platforms, but it will need to
> be clear that it's not portable.

I don't see why it wouldn't be possible to deploy the (big-endian) binary
files to any platform. Getting it into this binary form (using zone info
compiler zic) may be harder to do cross-platform, but cygwin may help here.

[snip]

> As the primary maintainer of Boost date-time I can say with certainty that
> there is interest in this functionality -- it's long been on my todo list
> and I haven't had time to get to it.  You can email me privately and we
> can discuss all the details of how to get your code incorporated.

I'll do!

Regards,

Rutger

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [date_time] Time zone improvements

Luke Camden
Rutger ter Borg-2 wrote
I would like to bring the full Olson tz database [1] to Boost.Date_Time

...

Jeff Garland wrote:

> Very cool :-) One question -- is there a portable solution where a user
> could deploy a files onto a Windows system or is it a Unix only solution?
> I'm fine with incorporating a *nix only solution because what your
> suggesting will be a nice solution for *nix platforms, but it will need to
> be clear that it's not portable.

I don't see why it wouldn't be possible to deploy the (big-endian) binary
files to any platform. Getting it into this binary form (using zone info
compiler zic) may be harder to do cross-platform, but cygwin may help here.

[snip]

> As the primary maintainer of Boost date-time I can say with certainty that
> there is interest in this functionality -- it's long been on my todo list
> and I haven't had time to get to it.  You can email me privately and we
> can discuss all the details of how to get your code incorporated.

I'll do!

Regards,

Rutger
Hi all,

Apologies for digging up the past, but did this lead to anything? Did time_zone_base prove to be an adequate abstraction in this case?

Best regards,
Luke
Reply | Threaded
Open this post in threaded view
|

Re: [date_time] Time zone improvements

Artyom Beilis
> >
> >> As the primary maintainer of Boost date-time I can  say with certainty
> >> that
> >> there is interest in this  functionality -- it's long been on my todo list
> >> and I haven't had  time to get to it.  You can email me privately and we
> >> can  discuss all the details of how to get your code incorporated.
> >
> >  I'll do!
> >
> > Regards,
> >
> > Rutger
> >
>
> Hi  all,
>
> Apologies for digging up the past, but did this lead to anything?  Did
> time_zone_base prove to be an adequate abstraction in this  case?
>
> Best regards,
> Luke
>
>


>From the last look I had took on tz support in
Boost.DateTime (a few weeks ago)

It is completely broken.

I mean the base class seems to be technically fine but the actually
timezone database in Boost.DateTime is broken.

The time zone rules it uses are too simplified and
don't cover real use cases where for example
DST is changed by more complex rules then
"First Saturday of May" but these rules should
rather vary per year as well.

For example Asia/Jerusalem time zone (mine)
is not represented correctly.

The correct implementation needs a full
implementation of Olson database, which
absent in Boost.

Artyom
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [date_time] Time zone improvements

Rutger ter Borg-2
In reply to this post by Luke Camden
On 2011-04-21 18:17, Luke Camden wrote:

> Hi all,
>
> Apologies for digging up the past, but did this lead to anything? Did
> time_zone_base prove to be an adequate abstraction in this case?
>
> Best regards,
> Luke
>

Hey Luke,

unfortunately my work didn't lead to anything yet except for having
implemented the ability to read and use the binary format of the
timezone database files (both the 32 and 64 bit parts).

time_zone_base has a couple of presumptions which prevent a correct
implementation of the Olson database:

1) dst_local_start_time / end_time assumes one such event per year (may
be less or more in time zone transition years / countries that don't do
DST). A correct interface should assume a series of zone transition
points (usually two per year for a given area/location).

2) all *zone_name, *zone_abbrev functions should be a function of time,
i.e., it needs a ptime parameter. The zone naming may change over time
(e.g., if a country changes their time zone).

Cheers,

Rutger


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [date_time] Time zone improvements

Stewart, Robert
In reply to this post by Artyom Beilis
Artyom wrote:

>
> > >> As the primary maintainer of Boost date-time I can  say
> > >> with certainty that there is interest in this
> > >> functionality -- it's long been on my todo list and I
> > >> haven't had  time to get to it.  You can email me
> > >> privately and we can  discuss all the details of how to
> > >> get your code incorporated.
> >
> > Apologies for digging up the past, but did this lead to
> > anything?  Did time_zone_base prove to be an adequate
> > abstraction in this case?
>
> From the last look I had took on tz support in
> Boost.DateTime (a few weeks ago)
>
> It is completely broken.
>
> I mean the base class seems to be technically fine but the
> actually timezone database in Boost.DateTime is broken.
>
> The time zone rules it uses are too simplified and don't
> cover real use cases where for example DST is changed by
> more complex rules then "First Saturday of May" but these
> rules should rather vary per year as well.

It is certainly deficient.  We have wrapped it here with a mechanism that locates rules based upon the year, but we merely smoothed over the multiple-changes-per-year problem by picking the dominant values for a given year.  It's a hack, but good enough for our purposes.

_____
Rob Stewart                           [hidden email]
Software Engineer                     using std::disclaimer;
Dev Tools & Components
Susquehanna International Group, LLP  http://www.sig.com



IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [date_time] Time zone improvements

Luke Camden
In reply to this post by Rutger ter Borg-2
Rutger ter Borg-2 wrote
Hey Luke,

unfortunately my work didn't lead to anything yet except for having
implemented the ability to read and use the binary format of the
timezone database files (both the 32 and 64 bit parts).

time_zone_base has a couple of presumptions which prevent a correct
implementation of the Olson database:

1) dst_local_start_time / end_time assumes one such event per year (may
be less or more in time zone transition years / countries that don't do
DST). A correct interface should assume a series of zone transition
points (usually two per year for a given area/location).

2) all *zone_name, *zone_abbrev functions should be a function of time,
i.e., it needs a ptime parameter. The zone naming may change over time
(e.g., if a country changes their time zone).

Cheers,

Rutger
Thanks, Rutger.

Realistically, is a change to time_zone_base a possibility? How many people depend directly on this interface? Or could we extend the interface with the required functions without breaking existing code?

Cheers,
Luke
Reply | Threaded
Open this post in threaded view
|

Re: [date_time] Time zone improvements

Luke Camden
In reply to this post by Stewart, Robert
Stewart, Robert wrote
Artyom wrote:
> It is completely broken.

It is certainly deficient.  We have wrapped it here with a mechanism that locates rules based upon the year, but we merely smoothed over the multiple-changes-per-year problem by picking the dominant values for a given year.  It's a hack, but good enough for our purposes.

_____
Rob Stewart                           [hidden email]
Software Engineer                     using std::disclaimer;
Dev Tools & Components
Susquehanna International Group, LLP  http://www.sig.com
Hi Rob,

Whose purposes is it good enough for? Does this mean you think there is no reason to 'correct' the API?

Cheers,
Luke
Reply | Threaded
Open this post in threaded view
|

Re: [date_time] Time zone improvements

Stewart, Robert
Luke Camden wrote:

> Stewart, Robert wrote:
> >
> > It is certainly deficient.  We have wrapped it here with a
> > mechanism that locates rules based upon the year, but we
> > merely smoothed over the multiple-changes-per-year problem
> > by picking the dominant values for a given year.  It's a
> > hack, but good enough for our purposes.
>
> Whose purposes is it good enough for? Does this mean you think
> there is no reason to 'correct' the API?

Between "we have wrapped it here" and my signature block, I thought it was obvious I was referring to my employer.  That does not mean the deficiency ought not to be corrected, just that what we've done has been good enough for our purposes.  Whether that will always hold I can't say.

_____
Rob Stewart                           [hidden email]
Software Engineer                     using std::disclaimer;
Dev Tools & Components
Susquehanna International Group, LLP  http://www.sig.com



IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [date_time] Time zone improvements

grubino
This post was updated on .
In reply to this post by Luke Camden
Greetings All (my very first post to the mailing list!),

Would it be possible to associate multiple instances of time_zone_base chained together with a local_date_time?  I'm sure that the local_date_time object doesn't support this, but maybe it would be less hazardous than a change to time_zone_base?

Edit: to clarify, I was thinking that more than two DST changes could be chained together this way, but now that I think about it, this idea is really hacky.

WRT the historical time zone change support, that's actually huge for me because without it I cannot use boost::date_time for most things.  I'm about to write my own wrapper for mining the zoneinfo DB for the POSIX string and use that to construct the time zone object.  It seems like in the case of simple DST zones (where DST is either on or off), historical TZ changes could be incorporated with another init constructor that takes the "US/Eastern" type string argument and then goes and queries the TZ DB whenever the user uses the time_zone_base_ptr to construct a local_date_time object.  I'll send code once I have it.

Regards,

Greg Rubino
FactSet Research Systems
Reply | Threaded
Open this post in threaded view
|

Re: [date_time] Time zone improvements

Stewart, Robert
grubino wrote:
>
> WRT the historical time zone change support, that's actually
> huge for me because without it I cannot use boost::date_time
> without it.

We found it necessary to create a mechanism for managing a reverse chronologically ordered set of time zone rules to account for historical changes.  We modified the zone names to include an optional delimiter and effective year which we split to regain the normal zone name and the year which is used as a key to finding the corresponding rule.  Thus, we determine the time zone data to apply to a given local_time by determining its year and then looking for the rule that was in effect as of that year.

Even with that logic, we still don't have support for zones with multiple transitions in a given year, such as occur when a state decides to ignore or recognize DST midway through a year or to switch from one time zone to another.

Perhaps we missed something in the provided time zone support that would have obviated our work.

_____
Rob Stewart                           [hidden email]
Software Engineer                     using std::disclaimer;
Dev Tools & Components
Susquehanna International Group, LLP  http://www.sig.com




IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost