So, people don't always pay attention to what they're reading?... strftime(3) says[0]:
"This has the same format and value as %Y, except that if the ISO week number belongs to the previous or next year, that year is used instead. (TZ (Calculated from tm_year, tm_yday, and tm_wday.)"
strftime has had this forever (my man page implies since C89), it's %c. of course, man pages being man pages, the recommendation to actually use it is neither at the top, nor the bottom, but hidden in the BUGS section.
date parsing is available in strptime. you have to write "%Y-%m-%d %T" (since for some reason only strftime supports %F), but that's not too bad. the major pain is handling locales in a thread-safe manner, which is unnecessarily painful in C.
> I still can't remember %m vs %M without thinking twice about it
The time component is "%H:%M:%S" — it's all capitals, and I always think "her majesty's ship" when I type it for some odd reason. At any rate, that's how I remember it.
Once I work out that time component, then the date falls into place: "%m-%d-%Y".
But yes, strftime's formatting strings aren't memorable.
(I'm also a server-side engineer, so I active try to avoid formatting dates into anything other than ISO-8601…)
Anything at all with strftime: Use %Y instead of %G. It's a C function, but many languages (Perl/Python/Ruby/etc.) expose it through their own datetime libraries.
Interesting. Given the documentation of strptime, I would have expected that to not be possible at all (since constructing a datetime without a year isn't possible directly)
In Java it's worse, for SimpleDateFormat (the most often used date formatter in Java) YYYY (uppercase) is "week year" (strftime %G), the correct way to get the year (strftime %Y) is yyyy (lowercase). It's very easy to get it wrong; the correct way to get the full ISO timestamp is "yyyy-MM-dd'T'HH:mm:ss.SSSXXX".
I assume they are using date-fns - Saw this bug in that lib once when doing a demo and it was really embarrassing.
You would expect a date processing library to somehow manage to not have bugs like this.
> The WEEKDAY function returns incorrect values for dates before March 1, 1900. Because most users do not use dates before March 1, 1900, this problem is rare.
In my case I had a date that I needed to parse from JSON. It was in this format: 2012-01-21. I parsed it using YYYY-MM-dd. It should have been yyyy-MM-dd for the reasons above.
It is not technically a bug but it real easy to get wrong. Perhaps they should have picked sometimg other than YYYY for week years.
Been there, a TCL web script, IIRC. This led to religious processing of input with "regsub" (this predated TCL 8). Yuck.
Also once fixed an inherited awk script that malfunctioned at the end of year: a hardcoded month name array with November missing. To this day I always populate any such lookup with a loop and strftime() or appropriate.
I wonder if this would cause problems for daily cron scripts that run tasks by checking the date against == rather than than <. Not to mention monthly scripts that happen to run on that particular lost day.
Anyway, I love the passionate discussion programmers have when it comes to dates. Remember, it's only 86400 seconds that they are losing.
reply