Do not use 'week year': YYYY
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.
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
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?
Where can I file a bug report that the class name is wrong "SimpleDateFormat" ;-)
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.
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.
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.
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.
Fun fact: SimpleDateFormat is not thread-safe and needs external synchronization
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`
"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.
It concerns me greatly that I can't find if the week year is based on American or ISO weeks...
Relevant video: https://youtu.be/D3jxx8Yyw1c
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"
undefined
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....
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.
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".
undefined
Previously: https://rachelbythebay.com/w/2018/04/20/iso/