5 ms·

> Is it just me for thinking that using format strings instead of some strongly typed interface with verbose names for this is not great? Yes, but it would not

> Is it just me for thinking that using format strings instead of some strongly typed interface with verbose names for this is not great? Yes, but it would not have helped with the bug in question. The parallel bug for a strongly typed interface would be "year()" returning this monstrosity, while "iso_year()" or some other poorly named variant returning the expected year. No API is immune to footguns and bad design decisions.

cies 5y ago
It's harder to make that bug. The common case is "year of era", so it is likely to be used for "year()". On the other hand the much less often used "year of week" would be named "year_of_week()" and hence it is clear to everyone that's not likely what you want.
- nicoburns 5y ago
  > It's harder to make that bug. The common case is "year of era", so it is likely to be used for "year()". That would be the sane thing to do. But the same applies to `YYYY`: it should be used for "year of era". But it hasn't been and that's the problem here. For contrast in moment.js, YYYY and yyyy do what you expect and "week year" is GGGG or gggg.
  - masklinn 5y ago
    > That would be the sane thing to do. But the same applies to `YYYY`: it should be used for "year of era". Why? `yyyy` is simpler to type, so makes a lot more sense for "year of era". > For contrast in moment.js, YYYY and yyyy do what you expect and "week year" is GGGG or gggg. In LDML (which I assume is what SimpleDateFormat uses), the G field is already spoken for the era name (BC/BCE and AD/CE).
ljm 5y ago
I forgot how bad JS's date API was until I tried getting the year out of a date. var date = new Date() date.getYear() // 122 I plugged this into another object and couldn't understand why it was setting the date to 0122. Like, what significance does 122 years from 1900 even have? Turns out I had to use getFullYear, which is of course perfectly intuitive.
- zeroonetwothree 5y ago
  It made more sense before 2000 of course. And they can’t really change it without breaking many things.
- cookie_monsta 5y ago
  To be fair getYear has been deprecated for over 20 years (a bit after it was deprecated in Java for the same reason). The Y2K problem was a real thing in lots of places.
- iso1631 5y ago
  Well yes, as it's an extention of code written in the 1970s, when dates were most commonly referred to with 2 digits. Even when javascript was written (and likewise with things like perl and php - and of course the underlying function dated back to the 70s ), it was still quite common for people to write dates by hand as 6/6/96 for June 6th 1996, hence people would often write something like print day() + "/" + mon() + "/" + year() If you wanted to put a 4 digit year many people print day() + "/" + mon() + "/19" + year() After 2000 came round, many sites would claim the year was 19100, I still saw these sites until well into the late 00s However some people wrote print day() + "/" + mon() + "/" + (1900 + year()) Which would give the correct display. Changing year() from returning a 2 digit (which in the 80s and even in the 90s was often preferable) to 4 digits would be a breaking change. Changing it to being "the last two digits" rather than "number of years since 1900" would be a breaking change. That's not something that people like to do, hence things like "getFullYear" to return a 4 digit year (or 3 digit for <1000 etc)
- eCa 5y ago
  Back then it was quite common to only care about two-digit years, and by implication only years from the 20th century. This kind of feature[1] lead to many potential Y2K bugs. [1] Which it shares with Perl and probably many other languages.
  - jameshart 5y ago
    "Back then" for Javascript was 1995. The phrase "millennium bug" was already well established in the public mind by then.
steerablesafe 5y ago
Sure, the issue is somewhat orthogonal. But I assume they wanted to keep the format string parsing minimal, hence the single letter format specifiers. Once you have a strongly typed API, you are no longer bound by this and you can have sensible names.
masklinn 5y ago
> The parallel bug for a strongly typed interface would be "year()" returning this monstrosity, while "iso_year()" or some other poorly named variant returning the expected year. No, the parallel for this would be called `week_year()`, or `iso_week_year()`, to be paired with an `iso_week()` (or `year_week()` since there really is no other formal week-year).
- jameshart 5y ago
  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. 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. That's what having YYYY produce the week year feels like - a blatant violation of the principle of least surprise. 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.
  - masklinn 5y ago
    > 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).

cies 5y ago

It's harder to make that bug. The common case is "year of era", so it is likely to be used for "year()". On the other hand the much less often used "year of week" would be named "year_of_week()" and hence it is clear to everyone that's not likely what you want.

nicoburns 5y ago
> It's harder to make that bug. The common case is "year of era", so it is likely to be used for "year()". That would be the sane thing to do. But the same applies to `YYYY`: it should be used for "year of era". But it hasn't been and that's the problem here. For contrast in moment.js, YYYY and yyyy do what you expect and "week year" is GGGG or gggg.
- masklinn 5y ago
  > That would be the sane thing to do. But the same applies to `YYYY`: it should be used for "year of era". Why? `yyyy` is simpler to type, so makes a lot more sense for "year of era". > For contrast in moment.js, YYYY and yyyy do what you expect and "week year" is GGGG or gggg. In LDML (which I assume is what SimpleDateFormat uses), the G field is already spoken for the era name (BC/BCE and AD/CE).

ljm 5y ago

I forgot how bad JS's date API was until I tried getting the year out of a date. var date = new Date() date.getYear() // 122 I plugged this into another object and couldn't understand why it was setting the date to 0122. Like, what significance does 122 years from 1900 even have? Turns out I had to use getFullYear, which is of course perfectly intuitive.

zeroonetwothree 5y ago
It made more sense before 2000 of course. And they can’t really change it without breaking many things.
cookie_monsta 5y ago
To be fair getYear has been deprecated for over 20 years (a bit after it was deprecated in Java for the same reason). The Y2K problem was a real thing in lots of places.
iso1631 5y ago
Well yes, as it's an extention of code written in the 1970s, when dates were most commonly referred to with 2 digits. Even when javascript was written (and likewise with things like perl and php - and of course the underlying function dated back to the 70s ), it was still quite common for people to write dates by hand as 6/6/96 for June 6th 1996, hence people would often write something like print day() + "/" + mon() + "/" + year() If you wanted to put a 4 digit year many people print day() + "/" + mon() + "/19" + year() After 2000 came round, many sites would claim the year was 19100, I still saw these sites until well into the late 00s However some people wrote print day() + "/" + mon() + "/" + (1900 + year()) Which would give the correct display. Changing year() from returning a 2 digit (which in the 80s and even in the 90s was often preferable) to 4 digits would be a breaking change. Changing it to being "the last two digits" rather than "number of years since 1900" would be a breaking change. That's not something that people like to do, hence things like "getFullYear" to return a 4 digit year (or 3 digit for <1000 etc)
eCa 5y ago
Back then it was quite common to only care about two-digit years, and by implication only years from the 20th century. This kind of feature[1] lead to many potential Y2K bugs. [1] Which it shares with Perl and probably many other languages.
- jameshart 5y ago
  "Back then" for Javascript was 1995. The phrase "millennium bug" was already well established in the public mind by then.

steerablesafe 5y ago

Sure, the issue is somewhat orthogonal. But I assume they wanted to keep the format string parsing minimal, hence the single letter format specifiers. Once you have a strongly typed API, you are no longer bound by this and you can have sensible names.

masklinn 5y ago

> The parallel bug for a strongly typed interface would be "year()" returning this monstrosity, while "iso_year()" or some other poorly named variant returning the expected year. No, the parallel for this would be called `week_year()`, or `iso_week_year()`, to be paired with an `iso_week()` (or `year_week()` since there really is no other formal week-year).

jameshart 5y ago
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. 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. That's what having YYYY produce the week year feels like - a blatant violation of the principle of least surprise. 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.
- masklinn 5y ago
  > 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).