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:02:14

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

> On 11/30/16 19:14, Marshall Clow wrote:
>
>>
>> I haven't gathered up bugs out of trac - but rather just info from GitHub.
>> If you have opinions on these pull requests, etc. please chime in.
>>
>
> Although I'm not a CMT member, I'll add a few comments.
>
> Boost.DateTime
>> https://github.com/boostorg/date_time/pull/34 -- reduce exports;
>> controversial
>>
>
> I think, this one has its merit. I added a comment to the PR.
>
> 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 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"

Boost.Function
>> https://github.com/boostorg/function/pull/11 -- warning suppression in
>> clang
>>
>
> This one looks pretty safe to me. Could probably even make it in 1.63?
>
>
I think so.

Also, I have reviewed the changes between develop and master
for DateTime, Format, PropertyMap, and Signals, and I will be merging them
into master before the release.

-- Marshall