> The point is there's nothing about YYYY vs yyyy telling you at a glance that there is a significant semantic difference in the result.
There's the part that the entire LDML datetime grammar works like that.
Literally the next letter in your pattern will make it clear: M is the month, and m is the minute.
Which, granted, makes "y" designating the calendar year less than ideal as you'd want to pair Y with M, rather than y with M. Even more so as the 24-hour hour is H, so your standard ISO-8601 pattern is yyyy-MM-ddTHH:mm:ssZ which is... a bit of a mess casing-wise.
> Imagine an API which had methods 'getYear()' and 'GET_YEAR()' where the latter returns the payroll week year, while the former returns the, you know, actual year.
A big difference is the LDML pattern-space is rather more limited, and casing is definitely an important component of it.
> Which is why your op was saying this is like having an API where year() returns a surprising number thta isn't the year.
> You know, like JavaScript does.
If you want to rag on JS's datetime API, which really is Java's, first get in line, second getYear is hardly the worst offender (that belongs to the paired glue-eaters that are getDay and getDate).
But there's a little bit of a difference between mm/MM being minutes/months, where at least as someone thinking about datetime formatting you likely have a concept that the concepts of minutes and months are plausible things 'm' might stand for, vs. yyyy/YYYY where unless you've come across it before, the idea that there might be an inbuilt concept of a 'week year' is likely not going to be something that occurs to you.
I suppose the fact that both 'yyyy/mm/dd' and 'YYYY/MM/DD' produce values that are obviously wrong most of the time should be enough of an incentive for developers to go and look. up the codes. But that said, 'YYYY/MM/DD' produces what looks like the right answer for most of January...
There's the part that the entire LDML datetime grammar works like that.
Literally the next letter in your pattern will make it clear: M is the month, and m is the minute.
Which, granted, makes "y" designating the calendar year less than ideal as you'd want to pair Y with M, rather than y with M. Even more so as the 24-hour hour is H, so your standard ISO-8601 pattern is yyyy-MM-ddTHH:mm:ssZ which is... a bit of a mess casing-wise.
> Imagine an API which had methods 'getYear()' and 'GET_YEAR()' where the latter returns the payroll week year, while the former returns the, you know, actual year.
A big difference is the LDML pattern-space is rather more limited, and casing is definitely an important component of it.
> Which is why your op was saying this is like having an API where year() returns a surprising number thta isn't the year.
> You know, like JavaScript does.
If you want to rag on JS's datetime API, which really is Java's, first get in line, second getYear is hardly the worst offender (that belongs to the paired glue-eaters that are getDay and getDate).