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

Subject: Re: [Boost-maint] Status of Boost.CMT libraries
From: Marshall Clow (mclow.lists_at_[hidden])
Date: 2016-11-30 13:39:21

On Wed, Nov 30, 2016 at 10:18 AM, Andrey Semashev <andrey.semashev_at_[hidden]
> wrote:

> 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?

Yes, you're correct - my internal auto-correct misfired.

> 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.

Agreed.   But people seem to have dealt with this inconsistency already
(for more than a decade)

> Maybe we should create a new function and deprecate to_posix_string? The
> new function could take an argument to select the desired behavior.
>
>
That could work.
I just don't want to break the existing users.
(I suspect there are many)

-- Marshall