81–90 of 167 posts
Earlier quoted context omitted.
Pro tip: never ever use anything but ISO dates in UTC tz unless you're displaying it for a user in a UI.
Proer tip: never use anything but unix timestamp until presentation.
Hang on, slashes and year-month-day? https://en.wikipedia.org/wiki/ISO_8601 Handed down by the ISO, The Great Compromise allows YYYY-MM-DD (or YYYYMMDD if you're in a hurry) but the version with slashes I'd find ambiguous and upsetting, especially early in the month. The standard is good, and you can get it from `date -I`. Hell mend anyone who messes with the delimiters or writes the year in octal or any other heresy…
Pro tip: never ever use anything but ISO dates in UTC tz unless you're displaying it for a user in a UI.
Either use dedicated "from_iso8601" functions, or manually specify the format of the input string ("%Y%m%dT%H%M%SZ")
In Sweden, we can write dates as 28/5-25
As another swede, I dare you! We swedes use standardized ISO 8601 dates such as YYYY-MM-DD as dictated by our excellent government and you find it in use in our social security number, government correspondence and mostly everywhere.
Same here in germany! ...Which is the reason why everyone ignores it in favour of the traditional format.
I love democracy, and also mountain-shaped temporal unit ordering ^ It's 28.05.2025 13:15.
Text-ordering by date is a nightmare because everything is first grouped by day-of-month, then month, then year! :)
I recently spent 2 hours on finding the bug, precisely because JS can't comprehend dates/times without a Unix timestamp underneath. I'd take a date from Postgres as e.x. "2025-05-24" and the first time somewhere deep in the package I was using, when JS encountered that, it needed to add a time (midnight, that's sane) and timezone (local time :) ). I was trying to use UTC everywhere and since the read dates had midnig…
> it needed to add a time (midnight, that's sane) Is it sane? Is midnight at the start of a day, or the end of it? I'd think noon would be less ambiguous, and significantly less prone to these timezone issues (although this may not be a benefit).
Midnight at the start of the day: 00:00:00
Midnight at the end of the day: 24:00:00
Earlier quoted context omitted.
Pro tip: never ever use anything but ISO dates in UTC tz unless you're displaying it for a user in a UI.
And unless you need the original date, time and time zone. Conversion to UTC is not injective e.g. when clocks change or politics happen
I am not sure why my brave browser does not console out the error as in the OP console.log(new Date('2025/05/28').toDateString()); console.log(new Date('2025-05-28').toDateString()); console.log(new Date('2025-5-28').toDateString()); OutPut Below Wed May 28 2025 debugger eval code:1:9 Wed May 28 2025 debugger eval code:2:9 Wed May 28 2025 debugger eval code:4:9
Obligatory: https://www.destroyallsoftware.com/talks/wat
Earlier quoted context omitted.
Pro tip: never ever use anything but ISO dates in UTC tz unless you're displaying it for a user in a UI.
RFC3339. ISO 8601 allows for 2 or 6 digit years. Truncating to 2 is just incorrect, and 6 digits is absurd. And you can read the RFC without paying ISO - and you can discuss the RFC with people who have also read it instead of relying on people using the Wikipedia page to interpret and explain ISO 8601. I have a scheduling service at work and I keep getting requests for implementing ISO 8601 timestamps but I ignore t…
Hang on, slashes and year-month-day? https://en.wikipedia.org/wiki/ISO_8601 Handed down by the ISO, The Great Compromise allows YYYY-MM-DD (or YYYYMMDD if you're in a hurry) but the version with slashes I'd find ambiguous and upsetting, especially early in the month. The standard is good, and you can get it from `date -I`. Hell mend anyone who messes with the delimiters or writes the year in octal or any other heresy…
Pro tip: never ever use anything but ISO dates in UTC tz unless you're displaying it for a user in a UI.
(Example - you want to know if a person is old enough to buy cigarettes, and you need to store a birthday that you can compare against the current day to see if they're legally 18 - if you store an epoch at UTC, do you store the time of day they were born? That's not the way the law works. Do you store midnight UTC? If they're currently in NY, can they but cigarettes at 7pm the day before their birthday because they're currently 18 in London?)
Sometimes you need a logical calendar date, not a point in time in the history of the universe.