juce::Time ISO8601 epoch start parsing inconsistency with UTC

General JUCE discussion
1

Hi,
I have a little problem with juce::Time converting to and from ISO8601 string format withing different UTC than 0. I live in UTC +1.
When I create a Time with 0 and convert it to string format, it creates 1970-01-01T01:00:00.000+00:00 - one hour after midnight because of my UTC. Then when I convert it back, it creates Time with millisSinceEpoch = 3600000.

juce::Time zero(0);						// millisSinceEpoch = 0
auto t1 = zero.toISO8601(true);
auto tt1 = juce::Time::fromISO8601(t1);	// // millisSinceEpoch = 3600000

I would like to have some consistency - I need to check if the time I created from 0 is actually from 0 or actually 1hr after midnight.
I mean it represents a last time device has connected to my app (0 if it never connected), so I could just check if the time is below 1980 or something, but it seems a bit silly.
And creating Time(0), converting it to ISO8601 and back and then compare seems a bit silly as well.

Any ideas?

(testing on Windows so far)

2

Surprisingly on macOS this back and forth conversion produces millisSinceEpoch = 0.

3

Thanks I’ve managed to replicate the issue, it looks like mtkime isn’t behaving as expected on Windows. I’ll see if I can find an alternative.

1 Like
4

This turned out to be an edge case with mtkime on Windows. It seems if you pass a value close to epoch (in this case we are actually passing epoch) and the UTC offset takes it out of a valid date range then mtkime will fail. This is the quote from the Microsoft documentation.

After an adjustment to UTC, _mktime32 handles dates from midnight, January 1, 1970, to 23:59:59 January 18, 2038, UTC. _mktime64 handles dates from midnight, January 1, 1970 to 23:59:59, December 31, 3000. This adjustment may cause these functions to return -1 (cast to time_t , __time32_t or __time64_t ) even though the date you specify is within range. For example, if you are in Cairo, Egypt, which is two hours ahead of UTC, two hours will first be subtracted from the date you specify in timeptr ; the subtraction may now put your date out of range.

This means if your dates aren’t so close to epoch you should find there isn’t a problem.

Either way I’ve pushed a fix internally to adjust when values on or near epoch are passed in. I’ll let you know when that makes it into develop.

1 Like
5

Thanks for reporting this issue, we recently pushed a fix for this.

1 Like