test_chrono_system_clock_roundtrip_time fails on my system between midnight and 1 o'clock.
Demonstrated by @henryiii in these tests (when run from a timezone in the eastern hemisphere): master...henryiii:fix/timebug
Further investigation shows that a negative number of microseconds is passed to PyDateTime_FromDateAndTime (in cast), resulting in an C API error that's not handled.
Current hypothesis of what goes wrong:
- Converting a Python
datetime.time to C++ adds 1 January, 1970 as date in a std::tm struct.
- This is then converted to a
<chrono> type through system_clock::from_time_t(std::mktime(...)), turning the clock back an hour to convert to UTC (I'm the CET time zone UTC+01:00 - ignoring summer time) .
- This results in a "negative" time. When converting back to Python,
(duration_cast<us_t>(src.time_since_epoch() % seconds(1))).count() results in a negative number.
test_chrono_system_clock_roundtrip_timefails on my system between midnight and 1 o'clock.Demonstrated by @henryiii in these tests (when run from a timezone in the eastern hemisphere): master...henryiii:fix/timebug
Further investigation shows that a negative number of microseconds is passed to
PyDateTime_FromDateAndTime(incast), resulting in an C API error that's not handled.Current hypothesis of what goes wrong:
datetime.timeto C++ adds 1 January, 1970 as date in astd::tmstruct.<chrono>type throughsystem_clock::from_time_t(std::mktime(...)), turning the clock back an hour to convert to UTC (I'm the CET time zone UTC+01:00 - ignoring summer time) .(duration_cast<us_t>(src.time_since_epoch() % seconds(1))).count()results in a negative number.