51–60 of 94 posts
"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...
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.
This kind of feature[1] lead to many potential Y2K bugs.
[1] Which it shares with Perl and probably many other languages.
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() + "-" + date.getMonth() + "-" + date.getDay()
The actual result for that date is "122-0-2" - not a single component of the date was what I expected.
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.
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)
Earlier quoted context omitted.
There is no date formatting in JavaScript's standard library. External libraries tend to just fix this kind of thing with a breaking change.
There is – here’s the spec: https://tc39.es/ecma402/#datetimeformat-objects
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.
Earlier quoted context omitted.
> 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.
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)
A linter should probably flag any format that mixes "week year" with month and days. It's really for use by itself or with payroll week number.
Earlier quoted context omitted.
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.
That's perhaps true, but there is no reason why we can't have both. There are many hard-coded format strings in practice.