[Boost-bugs] [Boost C++ Libraries] #6045: Date/Time: dst_calculator::local_is_dst doesn't deal with DST changeover at end of day

Subject: [Boost-bugs] [Boost C++ Libraries] #6045: Date/Time: dst_calculator::local_is_dst doesn't deal with DST changeover at end of day
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2011-10-20 23:26:33


#6045: Date/Time: dst_calculator::local_is_dst doesn't deal with DST changeover at
end of day
------------------------------------------------+---------------------------
 Reporter: Matt Adam <matt.adam@…> | Owner:
     Type: Bugs | Status: new
Milestone: To Be Determined | Component: None
  Version: Boost 1.47.0 | Severity: Problem
 Keywords: |
------------------------------------------------+---------------------------
 Hello boosters,

 dst_calculator::local_is_dst assumes that the hour lost in the "forward"
 DST changeover (in Spring, when DST begins) fully occurs within a single
 day. If your time zone rule specifies that DST begins at 23:59:99.999 on
 October 15th, with a duration of an hour, and you attempt to create a
 ptime for 00:00:00.000 on October 16th, it will succeed even though it
 ought to return invalid_time_label.

 I admit that this seems like an odd case, and personally I would expect
 all DST offsets to be in the 0h-3h range. However if you are creating
 custom time zones based on the win32 time zone information, the
 GetTimeZoneInformation API returns a TIME_ZONE_INFORMATION struct with
 values returned a millisecond before midnight. Specifically this happens
 with Brasilian standard/daylight time.

 For now I am "cleaning up" these odd values returned from windows, but
 boost probably should do this calculation correctly to begin with.

 I can provide a repro case if need be, although I think the behaviour of
 the code in question is pretty clear.

 Thanks,

 Matt Adam

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/6045>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.

This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:07 UTC