#InvoiceNinja, a dedicated timesheets and invoicing web application, being somehow unable¹ to consistently support #ISO8601 for timesheets, gives me very strong #KRAZAM "Microservices vs ISO timestamps" satyre sketch² vibes.
I wish this was a joke on the part of the InvoiceNinja people, but apparently they can't figure out how to have their settings for YYYY-MM-DD dates & 24-hour times actually apply consistently for input in the UI 🤦♂️
I find it sad that people can (righteously) hate on Fahrenheit for not being an international standard and mostly only understood in the US but then in their next beat try to argue for their local ddmmyy or otherwise nonsense numeric date formatting (eg mmddyy) not realizing they are using a date format equivalent. If you want to use local formatting, write the months with a full year, or use the standard. 010203 is nonsense; Jan. 2 2003 and 2 Jan. 2003 are clear, 2003-01-02 is best.
(Following iso 8601 date format; year, month day, 3 14 looks like pi. A great moment to celebrate pi. Almost as good as 6 28 which is tau day or twice pi day both good excuses to give out pie)
@Barredo That assumes local datetime is mostly useful. For me it's mostly not.
I want to be able to set date/time format separate from language. Usually English, sometimes another language I can speak. But I always want #iso8601 (or #rfc3339) date time notation. In windows I can set that easily. Not in browsers, on Linux, most M365 applications don't follow the datetime setting, just the language setting. Some do, some follow the location setting, meaning three different formats.
I would implore you all to use ISO 8601 for dates (year-month-day, biggest to smallest)! I sent a message out to my team at my job about this before discovered that XKCD actually made a comic regarding this haha. My favorite feature is that it allows for “natural” (lexicographical) sorting so that you can just sort your files on your computer by name! It also plays nicely with file paths on operating systems since it does not use / to delineate year-month-day.
The ambiguity between month/day in many date systems really hurts my brain. I admit that I sometimes use the US-standard of month/day/year for those individuals whose brains are likely not ISO 8601 compliant.
@jacobydave DateTime's iso8601 is okay but it doesn't output time zone. You can find more complete #ISO8601 parser/formatter classes on #CPAN.
For #Perl scripts that need to run quickly and with low memory, you can also try @xdg's https://metacpan.org/pod/DateTime::Tiny, which provides a subset of the DateTime API for immutable objects while enabling you to "inflate" them to full DateTimes as needed
There are lots of things that make our bilingual (and truly multi-lingual… hello allophones) society here in #Montreal interesting and fun. Sometimes it's a pain, but we tolerate things like the inefficiency (~2x as much time) of announcements and speeches made in both french and english (even though nearly everyone understands both languages).
One thing that gets me a LOT, though, is MM-DD-YYYY in english and DD-MM-YYYY in french. It makes stuff like automating document scanning a real pain.
#ISO8601 is the one, true date format: YYYY-MM-DD (followed by HH:MM:SS as needed).
As a born #Montréaler who lived in the US for nearly 40 years,but who is moving back to the "Ontario suburbs" of Montréal, I got thoughts about this. I should probably write them out & post them. Eastern Ontario has been a revelation ... and we haven't even moved into the house yet.
Tech tip: On Linux, you can easily get the current date in ISO 8601 format, suitable for plugging into, say, HTML metadata, or an Eleventy template, using the command line:
date -Is
That's a capital I (as in ISO) and a lower-case s (as in seconds).
Adding #ISO8601 to my bio as it is the only way to use dates without any ambiguity. yyyy-mm-dd. Simple. Makes sorting possible and reliable. Yoda style Ah, date is month day year should be made a global crime IMHO ;)
Testing and asking how you know what you know is useful for knowledge building. Average accuracy isn't the goal of knowledge building, knowledge is the goal.
When informing action or when (for lack of a better word) betting, leaning a little more toward speculation is likely to result in more correct takes, by accepting a few bad takes. (Or use the language of type I and type II errors).