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

61–70 of 94 posts

Re: Do not use 'week year': YYYY

#61

Post by protomyth »

throw0101a wrote: post #39
protomyth wrote: post #7

I understand that "week year" is basically a payroll creation, but I am a bit concerned about the last few days of 2021 were logged as 2022, and Jan 1st 2022 was even logged as 2023. The last few days of 2021 logged as 2022 makes sense for payroll, but how the heck is Jan 1st 2022 put in the 2023 year?

> The last few days of 2021 logged as 2022 makes sense for payroll, but how the heck is Jan 1st 2022 put in the 2023 year? First off, I think you have a typo(?) with the "2023"? Because: * https://www.epochconverter.com/weeks/2022 The reason(s) why the week system was designed: > * All weeks have exactly 7 days, i.e. there are no fractional weeks. > * Every week belongs to a single year, i.e. there are no ambiguous o…

Nice explanation but I directly quoted the article. Karussell provided an explanation at https://news.ycombinator.com/item?id=29794778

Re: Do not use 'week year': YYYY

#62

Post by JimDabell »

nicoburns wrote: post #56
JimDabell wrote: post #45

Earlier quoted context omitted.

There is – here’s the spec: https://tc39.es/ecma402/#datetimeformat-objects

Ah yes. I can't use that yet due to lack of browser support so I forgot it existed.

It’s pretty well supported now – even Internet Explorer 11 has partial support. But if you need it, there’s a polyfill here: https://formatjs.io/docs/polyfills/intl-datetimeformat/

Re: Do not use 'week year': YYYY

#63

Post by capableweb »

s_m wrote: post #51
jameshart wrote: post #29

Earlier quoted context omitted.

I feel like I'm missing a few dots to connect that problem with the proposed solution...

Fix in one place, and it's fixed everywhere. Allegedly.

Is that the argument for or against monorepos? Because it could be seen with both sides as the proposed solution.

Re: Do not use 'week year': YYYY

#64

Post by pmulv »

fs111 wrote: post #4

Ha, I just fixed a similar thing at work right before Christmas. If you use java, consider using google error-prone. It has a check for that (and many other things) https://errorprone.info/bugpattern/MisusedWeekYear

Me too! It's crazy to me that I've never met you or the parent poster but we were living very similar lives the last week of the year due to the same Java DateTime design decision!

Re: Do not use 'week year': YYYY

#65

Post by cbsks »

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.

date.getYear()

  99:  1999
  100: 2000
  …
  122: 2022

Re: Do not use 'week year': YYYY

#67

Post by masklinn »

arghwhat wrote: post #21
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…

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

Re: Do not use 'week year': YYYY

#68

Post by russtrotter »

steerablesafe wrote: post #43
AtroxDev wrote: post #16

Earlier quoted context omitted.

I agree. I really like how the `time` crate[0] in the rust world handles this[1]. with your example: > format_description!("[year]/[month]/[day]") 0: https://crates.io/crates/time 1: https://time-rs.github.io/book/api/format-description.html

+1 for strongly typed and compile-time checked, but I'm still not a fan of a sub-language within a string literal. The language already has syntax to structure things, why make a separate language within strings?

In the context of the original article addressing Java 8, in the java.time.format package, there's a DateTimeFormatterBuilder that removes the sub-language element of the issue. With those builder methods, you can construct the fields in the order you want, with whatever precision, with padding, etc.

Re: Do not use 'week year': YYYY

#69

Post by masklinn »

nicoburns wrote: post #35
cies wrote: post #25

Earlier quoted context omitted.

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.

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

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

Re: Do not use 'week year': YYYY

#70

Post by masklinn »

protomyth wrote: post #7

I understand that "week year" is basically a payroll creation, but I am a bit concerned about the last few days of 2021 were logged as 2022, and Jan 1st 2022 was even logged as 2023. The last few days of 2021 logged as 2022 makes sense for payroll, but how the heck is Jan 1st 2022 put in the 2023 year?

> I understand that "week year" is basically a payroll creation

It's not, it's a fiscal, or more generally business creation, allowing businesses to express everything in weekly basis, with no variance (all weeks are 7 days mon-sun with no fractionals, and every week belongs to a single year with no ambiguity).

This is very, very common usage in european businesses, and even casual settings, to the extent that you'll have a hard time finding a physical calendar without weeks printed on it.

Post reply on HN