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

31–40 of 94 posts

Re: Do not use 'week year': YYYY

#31

Post by AtroxDev »

ape4 wrote: post #24
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

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

That's when you can be more precise if you want: `[year padding:zero repr:full base:calendar sign:automatic]`. The format is also checked on compile time.

Re: Do not use 'week year': YYYY

#33

Post by LinAGKar »

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?

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

Re: Do not use 'week year': YYYY

#34

Post by lukax »

ZiiS wrote: post #2

Where can I file a bug report that the class name is wrong "SimpleDateFormat" ;-)

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.

Re: Do not use 'week year': YYYY

#35

Post by nicoburns »

cies wrote: post #25
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…

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.

Re: Do not use 'week year': YYYY

#36

Post by layer8 »

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.

Re: Do not use 'week year': YYYY

#37

Post by lloydatkinson »

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…

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');

Re: Do not use 'week year': YYYY

#38

Post by [deleted] »

easbar wrote: post #17
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?

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

[deleted]

Re: Do not use 'week year': YYYY

#39

Post by throw0101a »

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

Re: Do not use 'week year': YYYY

#40

Post by steerablesafe »

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…

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.
Post reply on HN