Re: [Boost-maint] Status of Boost.CMT libraries

Subject: Re: [Boost-maint] Status of Boost.CMT libraries
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2016-11-30 13:18:11

On 11/30/16 21:02, Marshall Clow wrote:
> On Wed, Nov 30, 2016 at 9:15 AM, Andrey Semashev <andrey.semashev_at_[hidden]>
> wrote:
>>
>> https://github.com/boostorg/date_time/pull/29 -- switch +/- on parsing.
>>> Definitely correct, will break code.
>>>
>>
>> I think we should fix bugs even if it breaks code. We could try to make it
>> less painful though.
>
>
> I'm really reluctant to make this change. I see it breaking lots of
> people's code for a small benefit.
>
> Short synopsis:
> There are two ways to describe a timezone difference from GMT (only two?
> You must be mad! - Ok, two in this instance).
>
> * Going west is negative. This reflects the fact that the time "gets
> earlier" as you go west.  In this scheme, San Diego is GMT-8, or "8 hours
> behind GMT". When it's 8 AM in San Diego, then it's 4 PM in London. This is
> what the ISO specifies.  In my experience, this is what I see when people
> want to use time zones.
>
> * Going west is positive. This reflects the "amount of time that needs to
> be added to the local time to get to GMT.  In this scheme, San Diego is
> GMT+8.  This is what Posix specifies.
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html
>
> Boost.DateTime has a call named posix_time_zone

to_posix_string?

> but it implements ISO time
> zone semantics.
>
> I asked Jeff Garland about this a while back, and he was horrified at the
> idea of breaking everyone's code for this.  His response was "Change the
> docs, don't break code"

Thing is, the function have POSIX in its name, so POSIX semantics is 
implied. Maybe we should create a new function and deprecate 
to_posix_string? The new function could take an argument to select the 
desired behavior.