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

21–30 of 94 posts

Re: Do not use 'week year': YYYY

#21

Post by arghwhat »

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

Re: Do not use 'week year': YYYY

#22

Post by rob74 »

ZiiS wrote: post #2

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

I think the name is wholly justified - it does offer (at least) one simple and effective way to shoot yourself in the foot...

Re: Do not use 'week year': YYYY

#24

Post by ape4 »

AtroxDev wrote: post #16
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…

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

Re: Do not use 'week year': YYYY

#25

Post by cies »

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…

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.

Re: Do not use 'week year': YYYY

#27

Post by layer8 »

gerikson wrote: post #20

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

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

Re: Do not use 'week year': YYYY

#29

Post by jameshart »

s_m wrote: post #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.

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

Re: Do not use 'week year': YYYY

#30

Post by ljm »

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…

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.

Post reply on HN