Hi Leon, Yes, but the problem is that the offset for Berlin in Boost date_time_zonespec.csv is +01, not -01 n Mats Från: Boost-users [mailto:boost-users-bounces@lists.boost.org] För Leon Mlakar via Boost-users Skickat: den 28 december 2018 22:18 Till: boost-users@lists.boost.org Kopia: Leon Mlakar Ämne: Re: [Boost-users] Question on Posix timezone string On 28.12.2018 21:34, Mats Webjörn/WIKAB via Boost-users wrote: I'm using Boost 1.66 and use the following code to get a Posix string to set my uCLinux TZ environment variable to get a local time from an UTC time #include #include tz_database tz_db; tz_db.load_from_file("./date_time_zonespec.csv"); time_zone_ptr nyc = tz_db.time_zone_from_region("Europe/Stockholm"); auto s = nyc->to_posix_string(); // "CET+01CEST+01,M3.5.0/02:00,M10.5.0/03:00" setenv("TZ", s.c_str(), 1); The odd thing is that my localtime becomes incorrect, and is actually 1 hr wrong on the opposite side of UTC. But, when I read https://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html it says "The offset specifies the time value you must add to the local time to get a Coordinated Universal Time value". Not add to UTC time, which seems like the Boost Posix string assumes !!!!! Which explains why 16:00 UTC give 15:00 CET instead of 17:00 which is the correct value, when using localtime_r(). I think this document is correct, and that POSIX systems actually add the TZ offset to the displayed local time to yield UTC, unlike to ISO 8601 where offset is subtracted from the local time (or, change the sign of the offset, then add :-) in the time string, to get the UTC . Five minutes past noon on one winter day in Berlin would thus be 12:05:00 with TZ offset -01 on Posix system and 12:05:00+01 in ISO 8601 textual presentation. Cheers, Leon

On 28.12.2018 22:30, Mats Webjörn/WIKAB wrote:

Hi Leon,

Yes, but the problem is that the offset for Berlin in Boost date_time_zonespec.csv is +01, not -01

Yeah, I got that, just wanted to confirm that you read the Posix docs correctly. I tried your code with older Boost (1.62) on my Mac and got the same string you put in comment (CET+01CEST+01,M3.5.0/02:00,M10.5.0/03:00) and if I feed this string to my TZ, for sure the output of date command is two hours off. It seems that to_posix_string() is broken. I think that the author of the library may have incorrectly interpreted the standard; unfortunately I don't have a copy of ISO/IEC 9945-1 at hand so I can't confirm that. But a quick Internet search for examples shows strings such as PST8PDT7,M4.1.0/2:00:00,M10.5.0/2:00:00 (US/Pacific), which indicate that the timezones west of GMT have positive offsets, which also means that Central Europe should have negative offsets. Also, the Boost documentation (https://www.boost.org/doc/libs/1_69_0/doc/html/date_time/local_time.html#dat...) states (Introduction, near the top):     'std' specifies the abbrev of the time zone. 'offset' is the offset from UTC Which would explain the incorrect signs ... in Posix it's the other way around, the offset is really the offset of UTC from the local time. Of course, all that will not help you, the results will still be incorrect. The only course of action I can recommend is to check what exactly ISO/IEC 9945-1 states, and if above is correct, fill a bug report at Boost. Unfortunately I can't think of any short term solution, other than looking for a different library. Cheers, Leon

nMats

*Från:*Boost-users [mailto:boost-users-bounces@lists.boost.org] *För *Leon Mlakar via Boost-users *Skickat:* den 28 december 2018 22:18 *Till:* boost-users@lists.boost.org *Kopia:* Leon Mlakar *Ämne:* Re: [Boost-users] Question on Posix timezone string

On 28.12.2018 21:34, Mats Webjörn/WIKAB via Boost-users wrote:

I’m using Boost 1.66 and use the following code to get a Posix string to set my uCLinux TZ environment variable to get a local time from an UTC time

#include

#include

tz_database tz_db;

tz_db.load_from_file("./date_time_zonespec.csv");

time_zone_ptr nyc = tz_db.time_zone_from_region("Europe/Stockholm");

auto s = nyc->to_posix_string();  // "CET+01CEST+01,M3.5.0/02:00,M10.5.0/03:00"

setenv("TZ", s.c_str(), 1);

The odd thing is that my localtime becomes incorrect, and is actually 1 hr wrong on the opposite side of UTC.

But, when I read https://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html it says

“The offset specifies the time value you must *_add to the local time_* to get a Coordinated Universal Time value”.

Not add to UTC time, which seems like the Boost Posix string assumes !!!!!

Which explains why 16:00 UTC give 15:00 CET instead of 17:00 which is the correct value, when using localtime_r().

I think this document is correct, and that POSIX systems actually add the TZ offset to the displayed local time to yield UTC, unlike to ISO 8601 where offset is subtracted from the local time (or, change the sign of the offset, then add :-) in the time string, to get the UTC .

Five minutes past noon on one winter day in Berlin would thus be 12:05:00 with TZ offset -01 on Posix system and 12:05:00+01 in ISO 8601 textual presentation.

Cheers,

Leon

Bugreport filed to Boost date-time (prime suspect to_posix_string()). Thanks for giving a second opinion n Mats Från: Leon Mlakar [mailto:leon@digiverse.si] Skickat: den 28 december 2018 23:37 Till: Mats Webjörn/WIKAB; 'boost-users@lists.boost.org' Ämne: Re: SV: [Boost-users] Question on Posix timezone string On 28.12.2018 22:30, Mats Webjörn/WIKAB wrote: Hi Leon, Yes, but the problem is that the offset for Berlin in Boost date_time_zonespec.csv is +01, not -01 Just to avoid ambiguity - it's probably not the date_time_zonespec.csv entry that is broken (local system may use any notation they wish), and from what I saw Boost.DateTime does not claim that this file has contains Posix strings. Quite the opposite, the documentation on the offset field is very explicit: - GTM offset: This is the number of hours added to utc to get the local time before any daylight savings adjustments are made. Some examples are: America/New_York offset -5 hours, and Africa/Cairo offset +2 hours. The format must follow the length-of-time format described above. On the other hand, the documentation for to_posix_string() method does claim that it, in accordance with its name, returns a Posix compliant string. Cheers, Leon

And yet another issue with to_posix_strings() The 1.66 date_time_zonespec.csv returns for Europe/Stockholm "CET+01CEST+01,M3.5.0/02:00,M10.5.0/03:00" It's not only the sign of the offset which is incorrect, the DST offset is also incorrect. Acc.to POSIX "Environment variables" http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_... for "TZ" "offset Indicates the value added to the local time to arrive at Coordinated Universal Time" So, the DST offset is NOT an offset to be added to the standard (STD) offset. It should be the complete offset to be added to local time to get UTC. A correct POSIX string should therefore read: "CET-01CEST-02,M3.5.0/02:00,M10.5.0/03:00" Regards Mats Webjörn Från: Stian Zeljko Vrba [mailto:vrba@quine.no] Skickat: den 29 december 2018 07:30 Till: Mats Webjörn/WIKAB; boost-users@lists.boost.org Ämne: Re: [Boost-users] Question on Posix timezone string To add another data point to the discussion as I've been bitten by the same issue wrt dates and times. I found the following comment in my code while translating local time to utc time by using Windows native and .NET APIs: // .Net DateTimeOffset contains _local_ ticks + offset, so that utc = local - offset // Windows TZ information contains bias which is -offset so that utc = local + bias It seems that there is a difference between "offset" and "bias". [1] contains the following text and formula: "The bias is the difference, in minutes, between Coordinated Universal Time (UTC) and local time [...] UTC = local time + bias." [2] on the other hand operates with offsets and says "The difference between the current DateTimeOffset object's time value and Coordinated Universal Time (UTC)." So that the TZ table contains negated offsets is plausible. [1] https://docs.microsoft.com/en-us/windows/desktop/api/timezoneapi/ns-timezone... [2] https://docs.microsoft.com/en-us/dotnet/api/system.datetimeoffset.offset?vie...