Change Details

`time.ctime()` documentation is not clear on the maximum value supported, but we get a hint from documentation of related functions such as: https://docs.python.org/3/library/datetime.html#datetime.date.fromtimestamp On my machine, I see failures somewhere around `time.ctime(pow(2, 35))`, although it varies for some people: https://stackoverflow.com/questions/46133223/maximum-value-of-timestamp Until the 2038 Problem is reliably fixed everywhere, we should not rely on it when logging timestamps from tests, as these values will tend to prod boundary conditions (ie. very large and very small timestamps). However, not using ctime at all would be a net-negative for debugging purposes, so I've left it in for when timestamps are within a 32-bit range which should be valid on all systems.

`time.ctime()` documentation is not clear on the maximum value supported, but we get a hint from documentation of related functions such as: https://docs.python.org/3/library/datetime.html#datetime.date.fromtimestamp On my machine, I see failures somewhere around `time.ctime(pow(2, 35))`, although it varies for some people: https://stackoverflow.com/questions/46133223/maximum-value-of-timestamp Until the 2038 Problem is reliably fixed everywhere, we should not rely on it when logging timestamps from tests, as these values will tend to prod boundary conditions (ie. very large and very small timestamps).

`time.ctime()` documentation is not clear on the maximum value supported, but we get a hint from documentation of related functions such as: https://docs.python.org/3/library/datetime.html#datetime.date.fromtimestamp On my machine, I see failures somewhere around `time.ctime(pow(2, 35))`, although it varies for some people: https://stackoverflow.com/questions/46133223/maximum-value-of-timestamp Until the 2038 Problem is reliably fixed everywhere, we should not rely on it when logging timestamps from tests, as these values will tend to prod boundary conditions (ie. very large and very small timestamps). However, not using ctime at all would be a net-negative for debugging purposes, so I've left it in for when timestamps are within a 32-bit range which should be valid on all systems.