Do not use 'week year': YYYY

And it is not even thread safe. We found this out because we had some flaky e2e test that were run concurrently and only failed every few days. The parsed date was just a few hours away from the expected so at first we thought it had to be something wrong with timezones or NTP.

fs111• 5 years ago

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

nicbou• 5 years ago

Is there something similar for Python or JavaScript?

Cthulhu_2• 5 years ago

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

LinAGKar2• 5 years ago

There is Pylint for Python

pmulv• 5 years ago

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!

protomyth3• 5 years ago

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?

yholio• 5 years ago

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

easbar• 5 years ago

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.

karussell• 5 years ago

Yes! I just looked into it and the log itself was still 2022:

2022-12-31 23:16:54.013

And then our UI converted this entry into one with 2023

(it correctly assumes that the string is in UTC and then converted it to local time +1h)

LinAGKar2• 5 years ago

Shouldn't it be the other way around? The first days of 2022 were in week 52 of 2021

throw0101a• 5 years ago

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 or double-assigned weeks.
* The date directly tells the weekday.
* All week-numbering years start with a Monday and end with a Sunday.
* When used by itself without using the concept of month, all week-numbering years are the same except that some years have a week 53 at the end.

* https://en.wikipedia.org/wiki/ISO_week_date#Advantages

This makes perfect sense if your role is in bookkeeping / accounting / finance. Your life is based on pay periods and not on day-of-year/month. A particular pay day "belonging" to a particular year is a meaningless affectation: people need to get paid every two weeks come hell or high water, and anything that can complicate the smooth running of that process is discarded.

As for the algorithm:

The ISO 8601 definition for week 01 is the week with the first Thursday of the Gregorian year (i.e. of January) in it. The following definitions based on properties of this week are mutually equivalent, since the ISO week starts with Monday: […]

* https://en.wikipedia.org/wiki/ISO_week_date#First_week

protomyth3• 5 years ago

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

masklinn5• 5 years ago

This makes perfect sense if your role is in bookkeeping / accounting / finance. Your life is based on pay periods and not on day-of-year/month. A particular pay day "belonging" to a particular year is a meaningless affectation: people need to get paid every two weeks come hell or high water, and anything that can complicate the smooth running of that process is discarded.

It's not just payrolls, it's also things like deliveries or synchronisation. And saying "monday week 15" (or writing "W15 mon") aside from being short and precise can give a better ground for synchronisation or collision than "April 11th" e.g. the person you're talking to might know that every monday would be an issue and be able to say that that's not an option before even looking it up.

masklinn5• 5 years ago

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.

bhaak• 5 years ago

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.

Cthulhu_2• 5 years ago

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

steerablesafe5• 5 years ago

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.

AtroxDev2• 5 years ago

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

ape43• 5 years ago

This is easier to read but not descriptive enough since there are different kinds year, month, day. Year can be 2 digits, 4 digits, regular or week year. Month can have leading zero or not, long name, short, name. Day could be Julian, leading zero or not, day of the week, etc

steerablesafe5• 5 years ago

+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?

arghwhat• 5 years ago

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• 5 years 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.

ljm• 5 years 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.

steerablesafe5• 5 years 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.

masklinn5• 5 years 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).

layer84• 5 years ago

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.

steerablesafe5• 5 years ago

That's perhaps true, but there is no reason why we can't have both. There are many hard-coded format strings in practice.

yencabulator• 5 years ago

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

jameshart5• 5 years ago

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

lloydatkinson• 5 years ago

100% agreed with you. I do not understand why stringly typed date systems are still so prevalent.

When I write code that needs to format in different formats I always create well named, perhaps verbose but I don't care as it's now readable, functions such as this (ignore HN butchering the code):

    /\*
     \* Formats Date into "twelve hour time". For example, 3:23. This is "h:mm" format from date-fns.
     \* @param { Date } date The date.
     \* @returns { string } The formatted string.
     \*/
     export const formatAsTwelveHourTime = (date: Date) => format(date, 'h:mm');

zokier• 5 years ago

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.

fanf2• 5 years ago

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

aspartate• 5 years ago

IMHO we should be using explicit names in format strings such as `{year}`/`{week_year}` instead of remembering the differences between yyy, yyyy, YYYY and more.

lifthrasiir• 5 years ago

I would go further by removing {week_year}, and instead make any non-Gregorian calendar contextual, like: {iso_calendar: {year}-{week}-{weekday}}.

s_m2• 5 years ago

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

jameshart5• 5 years ago

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

s_m2• 5 years ago

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

svilenivanov• 5 years ago

Fun fact: SimpleDateFormat is not thread-safe and needs external synchronization

gerikson2• 5 years ago

It concerns me greatly that I can't find if the week year is based on American or ISO weeks...

layer84• 5 years ago

You configure that on the SimpleDateFormat’s Calendar (GregorianCalendar::setMinimalDaysInFirstWeek and setFirstDayOfWeek). The default is determined by the locale.

Aaron2222• 5 years ago

Relevant video: https://youtu.be/D3jxx8Yyw1c

ViniciusArnhold• 5 years ago

Another confusing thing is that in java's newer datetime api, java.time, yyyy is also incorrect as it means `year-of-era` while `u` means `year` so you would use `uuuu`

ape43• 5 years ago

Since week year is so rarely used and since SimpleDateFormat() can't be changed perhaps the compiler could give a warning if it sees week year hardcoded in a call to SimpleDateFormat(). If its really wanted an annotation could turn off the warning.

jmuguy• 5 years ago

This sort of thing gets developers thinking about how they could improve on the way dates and time are handled by various programming languages. Don't do it! I find it best to just change jobs whenever encountering any sort of task that requires dealing with dates, time, or worse - time zones.

dmatech• 5 years ago

At this point, there really should be some sort of compiler warning when using "YYYY" and "MM" in the same format string. GCC does vaguely similar things with printf-style formats.

ycIsGarbage• 5 years ago

Previously: https://rachelbythebay.com/w/2018/04/20/iso/

simon04• 5 years ago

I love Go's date format syntax:

The reference time used in these layouts is the specific time stamp: 01/02 03:04:05PM '06 -0700 (January 2, 15:04:05, 2006, in time zone seven hours west of GMT). That value is recorded as the constant named Layout, listed below. As a Unix time, this is 1136239445.
RFC3339 = "2006-01-02T15:04:05Z07:00"

https://golang.org/pkg/time/

gerikson2• 5 years ago

It only works well if you’re familiar with the US form of dates…

stunt• 5 years ago

Even then you still have to look it up when you haven't used it for a while. It's clever, but not intuitive.

AtlasBarfed• 5 years ago

Is it wrong to just use epoch seconds for practically everything, and view "The Date" as being a render/readonly thing? That should keep you safe, eliminates timezone madness, leap seconds, and all that craziness from time processing and quantification?

You know, assuming the earth's frame of reference....

xtajv• 5 years ago

Store timestamps as ISO8601 UTC with the best precision supported by your hardware.

Display timestamps however the user wants.

Do not roll your own timestamp code. See "Falsehoods programmers believe about time".

Do not use 'week year': YYYY

Related Stories