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
Is there something similar for Python or JavaScript?
Do not use 'week year': YYYY
11–20 of 94 posts
Re: Do not use 'week year': YYYY
#12I 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.
Re: Do not use 'week year': YYYY
#13I 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.
Re: Do not use 'week year': YYYY
#14I 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?
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 logsRe: Do not use 'week year': YYYY
#15Re: Do not use 'week year': YYYY
#16Is 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…
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
Re: Do not use 'week year': YYYY
#17I 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?
This only happened shortly after midnight on January 1st. So I guess this is somehow related to different time zones/offsets.