Closed bgentry closed 6 years ago
Thank you very much.
So the TimezoneInfo struct that Timex makes might be helpful. It gives date info like this:
iex(67)> Timex.Timezone.get("America/New_York", DateTime.utc_now) |> Map.from_struct()
%{
abbreviation: "EST",
from: {:sunday, {{2018, 11, 4}, {1, 0, 0}}},
full_name: "America/New_York",
offset_std: 0,
offset_utc: -18000,
until: {:sunday, {{2019, 3, 10}, {2, 0, 0}}}
}
So I guess we can extrapolate that any time
between :until
and :until + 1
should be time + 1
?
For the ambiguous case, I'll have to do a little more research on what the best practice is.
The dateutil.rrule tests for the Python dateutil.rrule
class has extensive tests, so maybe we can borrow some of those (with attribution of course :)
https://www.timeanddate.com/time/change/usa/new-york?year=2019
And yes, I did have to look at this visual to understand what's going on. :joy:
This adds additional test cases to #15 to verify the correct behavior around Daylight Saving Time boundaries.
Two of these tests are currently broken. They relate to times that would occur twice during the transition from daylight to standard time, or times that don't exist during the transition from standard to daylight time. These are explicitly detailed by RFC5545:
Here is the spring behavior correctly implemented in Google Calendar:
Here's the failure in this test as of now:
And the failure for the fall DST issue:
Note that the expected value here is also wrong because it has an ambiguous timezone result (since 1:30AM occurs twice). We likely need to explicitly choose the expected timezone for this result to make sure it is the UTC-7 / PDT value, not the UTC-8 PST value (or ambiguous).