Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Do not use 'week year': YYYY

github.com

Post reply on HN
Print view View original

71–80 of 94 posts

Re: Do not use 'week year': YYYY

#71

Post by jcranmer »

ljm wrote: post #30
arghwhat wrote: post #21

Earlier quoted context omitted.

> 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 d…

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 get Full Year, which is of course perfectly intuitive.

The JS Date API was cribbed wholesale from Java's java.util.Date, which was cribbed wholesale from POSIX (and thus Unix) date APIs, which was designed in the 1970s. But both of the cribbings preferred compatibility with the older API rather than fixing obvious warts in the API like "year is since 1900, not 1 BC" or "month is 0-based instead of 1-based."

Re: Do not use 'week year': YYYY

#73

Post by jameshart »

eCa wrote: post #52
ljm wrote: post #30

Earlier quoted context omitted.

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 get Full Year, which is of course perfectly intuitive.

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.

"Back then" for Javascript was 1995. The phrase "millennium bug" was already well established in the public mind by then.

Re: Do not use 'week year': YYYY

#74

Post by jameshart »

masklinn wrote: post #67
arghwhat wrote: post #21

Earlier quoted context omitted.

> 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 d…

> 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).

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.

Re: Do not use 'week year': YYYY

#75

Post by masklinn »

jameshart wrote: post #74
masklinn wrote: post #67

Earlier quoted context omitted.

> 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).

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 i…

> 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).

Re: Do not use 'week year': YYYY

#76

Post by yencabulator »

layer8 wrote: post #36
steerablesafe wrote: post #13

Is it just me for thinking that using format strings instead of some strongly typed interface with verbose names for this is not great? I would take `format(year(), '/', month(), '/', day())` over ad-hoc format strings by various APIs. Reading the docs further this also stands out: > For parsing with the abbreviated year pattern ("y" or "yy"), SimpleDateFormat must interpret the abbreviated year relative to some cent…

Format strings are intended to be configurable (possibly per user-interface language) and not necessarily hardcoded. A strongly-typed builder API might be useful, but if you need both programmatic specification and external configuration, format strings can fulfill both purposes, whereas only having a builder API doesn’t.

`{year}-{month}-{date}` then.

Re: Do not use 'week year': YYYY

#77

Post by fanf2 »

zokier wrote: post #48
steerablesafe wrote: post #13

Is it just me for thinking that using format strings instead of some strongly typed interface with verbose names for this is not great? I would take `format(year(), '/', month(), '/', day())` over ad-hoc format strings by various APIs. Reading the docs further this also stands out: > For parsing with the abbreviated year pattern ("y" or "yy"), SimpleDateFormat must interpret the abbreviated year relative to some cent…

Even as a proponent of strong typing, I fail to see how type system could have possibly helped in this case. Could you show some sort of example of how you envision types to be used here? Verbose naming, yes, on the other hand would probably have made the situation clearer.

Have distinct types for each calendar (Gregorian, Julian, ISO week, Islamic, Jewish, Chinese, etc.) so it becomes obvious when you are mixing calendars.

Re: Do not use 'week year': YYYY

#78

Post by jazzyjackson »

jasamer wrote: post #53
ljm wrote: post #30

Earlier quoted context omitted.

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 get Full Year, which is of course perfectly intuitive.

I used the JS Date API for the first time a few months ago, and wrote something like date.getYear() + "-" + date.getMonth() + "-" + date.getDay() in the hope of getting something like "2022-1-4". The actual result for that date is "122-0-2" - not a single component of the date was what I expected.

date.toLocaleDateString ("fr-CA") would have got you there, but yea agreed 0 indexed months are whack.

I'm sure you've read the docs since then but just for the viewers at home:

s/getYear/getFullYear

s/getDay/getDate

getYear is oldfashioned, years since 1900. getDay is day-of-the-week, 0 for Sunday, 1 for Monday, etc

Re: Do not use 'week year': YYYY

#79

Post by jameshart »

layer8 wrote: post #36
steerablesafe wrote: post #13

Is it just me for thinking that using format strings instead of some strongly typed interface with verbose names for this is not great? I would take `format(year(), '/', month(), '/', day())` over ad-hoc format strings by various APIs. Reading the docs further this also stands out: > For parsing with the abbreviated year pattern ("y" or "yy"), SimpleDateFormat must interpret the abbreviated year relative to some cent…

Format strings are intended to be configurable (possibly per user-interface language) and not necessarily hardcoded. A strongly-typed builder API might be useful, but if you need both programmatic specification and external configuration, format strings can fulfill both purposes, whereas only having a builder API doesn’t.

The best part is your format language can be extensible to support things like inline JNDI lookups...

Re: Do not use 'week year': YYYY

#80

Post by layer8 »

yencabulator wrote: post #76
layer8 wrote: post #36

Earlier quoted context omitted.

Format strings are intended to be configurable (possibly per user-interface language) and not necessarily hardcoded. A strongly-typed builder API might be useful, but if you need both programmatic specification and external configuration, format strings can fulfill both purposes, whereas only having a builder API doesn’t.

`{year}-{month}-{date}` then.

More like `{numeric-year-no-leading-zeros}-{zero-padded-numeric-month}-{zero-padded-numeric-day-of-month}`. It’s virtually impossible to make it both succinct and unambiguous.
Post reply on HN