You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Discussion in #27 revealed that our scheduling logic is untested with regard to timezones. We need at least these test cases:
WeeklySchedule instance provided with a tzinfo that matches a provided location.
expectation: getCivilTwilight should return the appropriate datetime for the location on a given date in the provided tzinfo timezone.
WeeklySchedule instance provided with a location and tzinfo=None.
expectation: getCivilTwilight should return the appropriate datetime for the provided location on a given date but in the timezone of the caller's OS.
WeeklySchedule instance provided with a tzinfo that is different from a provided location.
expectation: getCivilTwilight should return the appropriate datetime for the provided location on a given date but in the provided tzinfo timezone.
WeeklySchedule instance provided with a location and no tzinfo argument.
expectation: getCivilTwilight should return the appropriate datetime for the provided location on a given date but in the UTC timezone.
Choose a few sample dates, locations, and twilight times from timeanddate.com, no fancy web scraping needed.
Bonus: use dates/times/locations where DST is involved. For example, try a location where DST is not practiced (Arizona?) while providing a tzinfo where DST is in effect on the given day.
The text was updated successfully, but these errors were encountered:
Discussion in #27 revealed that our scheduling logic is untested with regard to timezones. We need at least these test cases:
WeeklySchedule
instance provided with atzinfo
that matches a provided location.getCivilTwilight
should return the appropriatedatetime
for the location on a given date in the providedtzinfo
timezone.WeeklySchedule
instance provided with a location andtzinfo=None
.getCivilTwilight
should return the appropriatedatetime
for the provided location on a given date but in the timezone of the caller's OS.WeeklySchedule
instance provided with atzinfo
that is different from a provided location.getCivilTwilight
should return the appropriatedatetime
for the provided location on a given date but in the providedtzinfo
timezone.WeeklySchedule
instance provided with a location and notzinfo
argument.getCivilTwilight
should return the appropriatedatetime
for the provided location on a given date but in the UTC timezone.Choose a few sample dates, locations, and twilight times from timeanddate.com, no fancy web scraping needed.
Bonus: use dates/times/locations where DST is involved. For example, try a location where DST is not practiced (Arizona?) while providing a
tzinfo
where DST is in effect on the given day.The text was updated successfully, but these errors were encountered: