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 robert.stewart@sig.com 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.

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 robert.stewart@sig.com 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.

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 -- View this message in context: http://boost.2283326.n4.nabble.com/date-time-Time-zone-improvements-tp265279... Sent from the Boost - Dev mailing list archive at Nabble.com.

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 robert.stewart@sig.com 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.