Live data from Hacker News

Do not use 'week year': YYYY

github.com

11–20 of 94 posts

Re: Do not use 'week year': YYYY

#11
post #6
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

Is there something similar for Python or JavaScript?

eslint is the de facto standard for Javascript, there may be rules or plugins to check for date formatting rules.

Re: Do not use 'week year': YYYY

#12
post #8

I don‘t know how many times I used the wrong M in various date formatters. Format specifiers shouldn’t be case sensitive. Better mnemonics would be even better.

It really is its own little DSL, and often subtly different yet similar enough across various languages. Compare also with printf and regular expressions.

Re: Do not use 'week year': YYYY

#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 century. It does this by adjusting dates to be within 80 years before and 20 years after the time the SimpleDateFormat instance is created. For example, using a pattern of "MM/dd/yy" and a SimpleDateFormat instance created on Jan 1, 1997, the string "01/11/12" would be interpreted as Jan 11, 2012 while the string "05/04/64" would be interpreted as May 4, 1964. During parsing, only strings consisting of exactly two digits, as defined by Character.isDigit(char), will be parsed into the default century. Any other numeric string, such as a one digit string, a three or more digit string, or a two digit string that isn't all digits (for example, "-1"), is interpreted literally. So "01/02/3" or "01/02/003" are parsed, using the same pattern, as Jan 2, 3 AD. Likewise, "01/02/-3" is parsed as Jan 2, 4 BC.

I hope nobody uses this to parse historical data that happens to become older than 80 years recently.

Re: Do not use 'week year': YYYY

#14

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?

Presumably with a code path similar to this:

  get date as (week year, month, day)
  add start_interval to date using regular time handling functions
  print "task scheduled to start on: ", date
When you run this code on 31 December 2021 and schedule the task to run 1 day later, you will see 2023 in the logs

Re: Do not use 'week year': YYYY

#16

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…

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

Re: Do not use 'week year': YYYY

#17

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?

> but how the heck is Jan 1st 2022 put in the 2023 year?

This only happened shortly after midnight on January 1st. So I guess this is somehow related to different time zones/offsets.

Re: Do not use 'week year': YYYY

#18
"week year" was the cause of a big Twitter outage during the time I worked there. In the immediate aftermath there was a "see? this is why we need a monorepo" exhortation from leadership.
Post reply on HN