id,summary,reporter,owner,description,type,status,milestone,component,version,severity,resolution,keywords,cc
4771,DST calculation inconsistencies,mika.heiskanen@…,az_sw_dude,"One local_date_time constructor takes as argument a date and a time duration. However, its behaviour is not consistent. First, define a date prior to a DST change in the spring (one day prior is sufficient). Then assume you have to skip N minutes into the future, where N is large enough to get past the DST change.

a) If you add floor(N/(24*60)) days to the date, and then construct a new local_date_time with the new date and N%(24*60) minutes, you get one result.

b) If you construct a local_date_time with the original date and the N minutes (>24*60) you get a second result.

The results are different by one hour for regular EU DST rules. It seems like the constructor will not inspect DST rules unless the input date coincides with the DST change date.

The effect:

Instead of looping with one origin time + advancing time_duration, we have to advance the date whenever the number of minutes exceeds 24*60 and take modulo 24*60 for the duration in minutes. This produces the correct behaviour for our application.
",Bugs,new,To Be Determined,date_time,Boost 1.44.0,Problem,,,