10 ms·
Do not use 'week year': YYYY
- s_m 5y 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.
- jameshart 5y agoI feel like I'm missing a few dots to connect that problem with the proposed solution...
- s_m 5y agoFix in one place, and it's fixed everywhere. Allegedly.
- capableweb 5y agoIs that the argument for or against monorepos? Because it could be seen with both sides as the proposed solution.
- fs111 5y agoHa, 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 https://errorprone.info/bugpattern/MisusedWeekYear
- nicbou 5y agoIs there something similar for Python or JavaScript?
- Cthulhu_ 5y agoeslint is the de facto standard for Javascript, there may be rules or plugins to check for date formatting rules.
- nicoburns 5y agoThere is no date formatting in JavaScript's standard library. External libraries tend to just fix this kind of thing with a breaking change.
- JimDabell 5y agoThere is – here’s the spec: https://tc39.es/ecma402/#datetimeformat-objects https://tc39.es/ecma402/#datetimeformat-objects
- nicoburns 5y agoAh yes. I can't use that yet due to lack of browser support so I forgot it existed.
- JimDabell 5y agoIt’s pretty well supported now – even Internet Explorer 11 has partial support. But if you need it, there’s a polyfill here: https://formatjs.io/docs/polyfills/intl-datetimeformat/ https://formatjs.io/docs/polyfills/intl-datetimeformat/
- LinAGKar 5y agoThere is Pylint for Python
- pmulv 5y agoMe 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!
- ZiiS 5y agoWhere can I file a bug report that the class name is wrong "SimpleDateFormat" ;-)
- capableweb 5y ago- https://docs.oracle.com/javase/10/troubleshoot/submit-bug-report.htm https://docs.oracle.com/javase/10/troubleshoot/submit-bug-re... - https://bugreport.java.com/bugreport/ https://bugreport.java.com/bugreport/
- hutzlibu 5y agoIt was a joke. Dates are not simple ..
- silon42 5y agothe thing obviously should be called: WYWY
- darrenkopp 5y agoCame here to post this, and to add the pronunciation guide as "why? why??"
- adam12 5y agoor just WWWW edit: this wouldn't work, since W is reserved for weeks in month
- rob74 5y agoI think the name is wholly justified - it does offer (at least) one simple and effective way to shoot yourself in the foot...
- lukax 5y agoAnd 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.
- protomyth 5y agoI 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 5y agoPresumably 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 5y 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.
- deleted 5y ago[deleted]
- karussell 5y agoYes! 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)
- protomyth 5y agoOk, you had me a bit worried on that one. 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.
- LinAGKar 5y agoShouldn't it be the other way around? The first days of 2022 were in week 52 of 2021
- bhaak 5y agoI 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_ 5y agoIt really is its own little DSL, and often subtly different yet similar enough across various languages. Compare also with printf and regular expressions.
- deleted 5y ago[deleted]
- steerablesafe 5y agoIs 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.
- AtroxDev 5y agoI 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 https://crates.io/crates/time 1: https://time-rs.github.io/book/api/format-description.html https://time-rs.github.io/book/api/format-description.html
- ape4 5y agoThis 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
- AtroxDev 5y agoThat'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.
- aspartate 5y agoIMHO 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 5y agoI would go further by removing {week_year}, and instead make any non-Gregorian calendar contextual, like: {iso_calendar: {year}-{week}-{weekday}}.
- svilenivanov 5y agoFun fact: SimpleDateFormat is not thread-safe and needs external synchronization
- gerikson 5y agoIt concerns me greatly that I can't find if the week year is based on American or ISO weeks...
- layer8 5y agoYou configure that on the SimpleDateFormat’s Calendar (GregorianCalendar::setMinimalDaysInFirstWeek and setFirstDayOfWeek). The default is determined by the locale.
- Aaron2222 5y agoRelevant video: https://youtu.be/D3jxx8Yyw1c https://youtu.be/D3jxx8Yyw1c
- ViniciusArnhold 5y agoAnother 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`
- ape4 5y agoSince 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 5y agoThis 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 5y agoAt 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 5y agoPreviously: https://rachelbythebay.com/w/2018/04/20/iso/ https://rachelbythebay.com/w/2018/04/20/iso/
- simon04 5y agoI 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/ https://golang.org/pkg/time/
- AtlasBarfed 5y agoIs 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 5y agoStore 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".
- deleted 5y ago[deleted]