Daylight savings incorrect due dates
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
Fix Released
|
Low
|
Unassigned | ||
3.1 |
Fix Released
|
Low
|
Unassigned | ||
3.2 |
Fix Released
|
Low
|
Unassigned |
Bug Description
Evergreen 2.11, affects all versions.
Creating a circulation between midnight and 1 am whose due date falls on the other side of the daylight savings boundary results in a circulation with a due date landing 1 day before the expected due date.
For example:
xact_start => 2016-10-10 00:05:00-07
due_date => 2016-11-06 23:59:59-08
To compare the expected behavior:
evergreen=# select '2016-10-10 00:05:00-
-[ RECORD 1 ]------
?column? | 2016-11-07 00:05:00-08
==
This is the result of (only) using interval_to_seconds when calculating the due date. Adding 28 days across a DST boundary is not the same as adding 2419200 seconds, since the DST switch-over day is longer.
As discussed in IRC, DateTime::add(days => ...) understands DST boundaries and handles them correctly. The plan is to teach the Perl code to take advantage of this fact by adding days, months, etc. (by leveraging seconds_
Changed in evergreen: | |
assignee: | nobody → Bill Erickson (berick) |
Changed in evergreen: | |
status: | New → Confirmed |
Changed in evergreen: | |
importance: | Undecided → Wishlist |
Changed in evergreen: | |
status: | Fix Committed → Confirmed |
Changed in opensrf: | |
status: | Fix Committed → Confirmed |
Changed in evergreen: | |
milestone: | 3.0-beta → 3.0-beta2 |
Changed in opensrf: | |
milestone: | 2.5.1 → 2.5.2 |
Changed in opensrf: | |
milestone: | 2.5.2 → 2.5.3 |
Changed in evergreen: | |
milestone: | 3.0-beta2 → 3.0-rc |
Changed in evergreen: | |
milestone: | 3.0-rc → 3.0.1 |
Changed in evergreen: | |
milestone: | 3.0.1 → 3.0.2 |
Changed in evergreen: | |
milestone: | 3.0.2 → 3.0.3 |
Changed in evergreen: | |
milestone: | 3.0.3 → 3.0.4 |
Changed in evergreen: | |
milestone: | 3.0.4 → 3.0.5 |
Changed in evergreen: | |
milestone: | 3.0.5 → 3.0.6 |
Changed in opensrf: | |
milestone: | 2.5.3 → 3.0.1 |
Changed in evergreen: | |
milestone: | 3.0.6 → 3.0.7 |
Changed in evergreen: | |
milestone: | 3.0.7 → 3.0.8 |
Changed in opensrf: | |
milestone: | 3.0.1 → 3.0.2 |
Changed in evergreen: | |
milestone: | 3.0.8 → 3.0.9 |
milestone: | 3.0.9 → 3.1.3 |
Changed in evergreen: | |
milestone: | 3.1.3 → 3.1.4 |
Changed in evergreen: | |
milestone: | 3.1.4 → 3.1.5 |
Changed in evergreen: | |
milestone: | 3.1.5 → 3.1.6 |
Changed in evergreen: | |
milestone: | 3.1.6 → 3.1.7 |
Changed in evergreen: | |
milestone: | 3.1.7 → 3.2.2 |
importance: | Wishlist → Low |
Changed in opensrf: | |
importance: | Wishlist → Low |
Changed in evergreen: | |
assignee: | Dan Wells (dbw2) → nobody |
status: | Fix Committed → Fix Released |
Changed in evergreen: | |
assignee: | nobody → Dan Wells (dbw2) |
Here's an experiment that calculates due dates based on what was discussed in IRC:
http:// irc.evergreen- ils.org/ evergreen/ 2016-10- 21#i_273165
http:// git.evergreen- ils.org/ ?p=working/ Evergreen. git;a=shortlog; h=refs/ heads/user/ berick/ lp1635737- due-date- interval- smarts
This has a number of problems, though. The normalization step, that cross-walks the duration string between interval_to_seconds then seconds_to_interval causes loss of information. For example, "30 days" becomes "1 month 14 hours" which, depending on when it's applied (e.g Feb 1), could be several days shy of "30 days".
I believe we either have the make the Perl interval parsing essentially as smart as PG's interval handling or ask PG to calculate the date for us.
On interesting side effect of this general approach -- honoring the lengths of various duration components based on when the components are applied -- means that we could create duration rules for 1 month and have the due dates always fall on the same day the following month, instead of falling exactly 30 days later regardless of what month it is. And in cases where that's not desired, using day-based durations will still behave as expected.