According to the Wikipedia article, the time returns at 2:00 a.m. EDT to 1:00 a.m. EST on the first Sunday in November. On November 4th, 2018, I observed that the time isn't set back at the correct time.
import arrow
just_before = arrow.get('2018-11-04T01:59:59.999999')
print(just_before) # prints 2018-11-04T01:59:59.999999+00:00
just_after = just_before.shift(microseconds=1)
print(just_after) # prints 2018-11-04T02:00:00+00:00
just_before_eastern = just_before.replace(tzinfo='US/Eastern')
print(just_before_eastern) # prints 2018-11-04T01:59:59.999999-04:00
just_after_eastern = just_after.replace(tzinfo='US/Eastern')
print(just_after_eastern) # prints 2018-11-04T02:00:00-05:00
The tzinfo is set back from -04:00 to -05:00 on November 4th, 02:00 UTC, which is November 3rd, 22:00 EDT.
Not sure if it may be a feature (UTC used as switch time for simplicity or consistency?). But logically it makes all the sense to switch from EDT to EST at proper local time, November 4th, 02:00. Which, in UTC, is November 4th, 06:00.
If we replace just_before in the code above to arrow.get('2018-11-04T05:59:59.999999'), the line with 'US/Eastern' timezone prints -05:00 already in just_before_eastern, which is incorrect.
I am beginning to look into this issue.
@ajdidonato7 and I think what was believed to be a bug was actually expected behavior.
This stems from the behavior that is described in the index.rst file "replaces the timezone without altering other attributes."
The user clearly shows the change occurring across the Eastern time zone, with
just_before_eastern = just_before.replace(tzinfo='US/Eastern')
print(just_before_eastern) # prints 2018-11-04T01:59:59.999999-04:00
just_after_eastern = just_after.replace(tzinfo='US/Eastern')
print(just_after_eastern) # prints 2018-11-04T02:00:00-05:00
However, their claim is that the bug is would occur if you "replace just_before in the code above to arrow.get('2018-11-04T05:59:59.999999')"
This outputs 2018-11-04T05:59:59.999999-05:00 which the user says is incorrect due to the offset which was changed at UTC instead of local time. However, the replace function does not change the time at all, only the offset. So the offset should have changed already by 5:59 (dst kicks in at 2am).
Thoughts on this? @jadchaar @akuzmichov I can produce test cases that confirm this if it is correct.
Most helpful comment
I am beginning to look into this issue.