Weirdness with juce::Time


DBG (juce::Time (2021, 6, 30, 0, 0).toString (true, true));


30 Jul 2021 12:00:00am

I was expecting

30 Jun 2021 12:00:00am

It’s not the conversion to string, since the internal representation of the Time object is

millisSinceEpoch	juce::int64	1627592400000

which i believe is Jul 30.

This happens on macOS.

The documentation for the Time constructor says :

month,	the month, in the range 0 to 11

Which is weird, because the documentation for the day says :

day,	the day of the month, in the range 1 to 31

Perhaps an ancient programming mistake in the Juce code, that couldn’t later be changed/fixed.

Oh shit! Didn’t expect this. I actually read the documentation, but this is the kind of stuff that just gets filtered out as impossible before reaching conciousness.

Thanks for your help!

FWIW JavaScript Date has the same convention for setting the month.

This perversion originates from the c standard

and goes from there to the c++ standard library which JUCE uses

Still, IMHO this is wrong to the extent that this constructor should be deprecated and replaced with a sensible one.

Interesting finding. I would suggest adding an enum to the time:

enum class Month
{ jan=0, feb, mar, apr, may, jun, jul, aug, sep, oct, nov, dec };

Then create an overload accepting the enum and maybe deprecate the old integer function. It doesn’t fit in 2021.

1 Like

That would be an improvement, but i you still wouldn’t have a constructor that accepts months numbered 1-12. Perhaps setting the enumeration to start from 1 instead of 0 would do the trick. That way you could say

Time (2021, Month (7), 2);

And actually get Jul 2 2021

However, the bottom line is that the current constructor is a trap and causes more harm than good and should be deprecated.

it´s a revolvind door trap, no matter from which side you come. If you are used to the wrong standard or if you use the sensible one. Supplying an integer will catch either one or the other group.