Hi, Il 10/07/2018 11:54, Vincent Lefevre ha scritto: > 2012-03-25 00:59:59 UTC was the change-second from standard to > daylight time, so the offset for times after 01:00:00 (as in your > examples) should be +2:00. 2017-10-29 00:59:59 UTC was similarly the > change back to standard time for that year, so times before that > should also be +2:00. The conversion is apparently mis-applying the > summer time offset on the transition days. That would be a bug in > boost::date_time; our formatter uses its operator<<.
Having finally had some time to debug, I believe that boost libraries are behaving as they should and the bug rests in the GnuCash's TimeZoneProvider, which provides a wrong time zone object in TimeZoneProvider::get(int) [1]. [1] https://sources.debian.org/src/gnucash/1:3.2-1/libgnucash/engine/gnc-timezone.cpp/#L738 To show this, I used the following code, inspired to LDT_from_unix_local[2]: time64 time = 1332640067; PTime temp(unix_epoch.date(), boost::posix_time::hours(time / 3600) + boost::posix_time::seconds(time % 3600)); auto tz = tzp.get(temp.date().year()); std::cout << tz->dst_local_start_time(2012) << std::endl; std::cout << tz->dst_local_end_time(2012) << std::endl; [2] https://sources.debian.org/src/gnucash/1:3.2-1/libgnucash/engine/gnc-datetime.cpp/#L142 The output is: > 2012-Mar-25 03:00:00 > 2012-Oct-28 02:00:00 While I believe the expected output is reversed: DST is entered at 02:00 and exited at 03:00 (a quick comparison with the file date_time_zonespec.csv distributed with boost seems to confirm). I did not study the code of TimeZoneProvider because it is rather complex and I am not very expert of the field; however it seems there is not boost logic inside. Please, let me know if you have comments, otherwise I will close the bug. Thanks, Giovanni. -- Giovanni Mascellani <[email protected]> Postdoc researcher - Université Libre de Bruxelles
signature.asc
Description: OpenPGP digital signature
