Earlier quoted context omitted.
Because Americans use slashes commonly in Y/D/M
Wait, I thought Americans use M/D/Y not Y/D/M?
OP is probably little-endian.
Why are 2025/05/28 and 2025-05-28 different days in JavaScript?
151–160 of 167 posts
Re: Why are 2025/05/28 and 2025-05-28 different days in JavaScript?
#152Hang 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…
> Hang on, slashes and year-month-day? I believe slashes are the most common separators in Japan (which uses that order), at least when explicit kanji for "year", "month" and "day" aren't used.
Periods as separators are also quite common.
Re: Why are 2025/05/28 and 2025-05-28 different days in JavaScript?
#153Earlier quoted context omitted.
> other languages & with bigger runtimes and more comprehensive standard libraries such as Java Java's Date standard lib was awful for 2 decades, so there's no guarantee that a big standard library is a good standard library.
Even in a good standard library, oddities arise. Many praise Go for its standard library but then there is its time format that raises an eyebrow: 01/02 03:04:05PM '06 -0700
Much like the traditional Unix date format, which for some reason puts the year at the end. Example from my computer:
$ date
Thu 29 May 13:12:30 JST 2025
Re: Why are 2025/05/28 and 2025-05-28 different days in JavaScript?
#154Re: Why are 2025/05/28 and 2025-05-28 different days in JavaScript?
#155Earlier 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.
Pro tip #2: never ever rely on automatic parsing of dates. It's a lie and will corrupt your data. Either use dedicated "from_iso8601" functions, or manually specify the format of the input string ("%Y%m%dT%H%M%SZ")
The list of things that devs should "never ever" do grows by the day... turns out most things, even the simplest of things, even sometimes the most apparently trivial things (like naming of people, too) are in reality almost always much more complex and difficult to get right on the first go than expected.
But then discussion ensues about how programmers these days add libraries as dependencies for almost everything! :-)
I guess at some point a middle ground must be found.
Re: Why are 2025/05/28 and 2025-05-28 different days in JavaScript?
#156Earlier quoted context omitted.
I disagree, store UTC time and the name of timezone it was originally recorded in so it can be translated back to that as well. UTC only loses information.
> and the name of timezone The problem is that can be difficult to portably determine. One wishes POSIX had an API “give me IANA time zone name for current process” which would do the needful to work it out (read TZ environment variable, readlink /etc/localtime, whatever else might be necessary)… but no, you are left to do those steps yourself. And it works reasonably well if the TZ environment variable is set, but i…
> I really wish Microsoft would ship the IANA database with Windows, and the IANA-Windows mapping table too, and provide APIs to query them, and keep them updated with Windows update.
I think they have done exactly what you describe for several years at least:
https://learn.microsoft.com/en-us/dotnet/api/system.timezone...
Re: Why are 2025/05/28 and 2025-05-28 different days in JavaScript?
#157Earlier 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.
I disagree, store UTC time and the name of timezone it was originally recorded in so it can be translated back to that as well. UTC only loses information.
You conceivably need more than that. You need to know the location (NOT just the time zone) where it will occur, the time zone that location was in when the meeting was created, and the time zone that location is in when the meeting actually happens. The users' systems or whatever does final display need to know their own time zone(s), and how to convert.
Say, for a somewhat annoying-case example, you want to store a meeting date/time that's in the future, in January, in the city of New York, New York, USA, with remote participants elsewhere in New York state. Sometime in between when the calendar invite is created and the meeting the city of New York decides to change to be on permanent Daylight Savings Time, but the rest of New York state doesn't change. If you stored only the UTC time and "America/New York" you now have an ambiguous meeting date/time, since the "America/New York" time zone split and the city of NY is an hour off from the rest of NY for part of the year, and your remote participants could get the wrong time.
There's probably an even worse case involving the death of a Japanese emperor, since the "period" portion of a Japanese date is the imperial name of the emperor who ruled at that time, and that gets retroactively applied to dates between when the new emperor's coronation and when they took their new imperial name.
Re: Why are 2025/05/28 and 2025-05-28 different days in JavaScript?
#158Earlier quoted context omitted.
> and the name of timezone The problem is that can be difficult to portably determine. One wishes POSIX had an API “give me IANA time zone name for current process” which would do the needful to work it out (read TZ environment variable, readlink /etc/localtime, whatever else might be necessary)… but no, you are left to do those steps yourself. And it works reasonably well if the TZ environment variable is set, but i…
> I really wish Microsoft would ship the IANA database with Windows, and the IANA-Windows mapping table too, and provide APIs to query them, and keep them updated with Windows update. I think they have done exactly what you describe for several years at least: https://learn.microsoft.com/en-us/dotnet/api/system.timezone...
That’s a .Net API, so not easily usable from native code. If they offered a C API instead, almost anything could feasibly use it.
Plus, from reading that doc, it sounds like it only works on Windows if you enable “App-Local ICU” mode, in which case the ICU DLL is added to your .Net app’s distributable package - which implies the info isn’t actually bundled with Windows itself
Consider Python’s zoneinfo standard library module-it provides access to IANA TZ database. On all platforms except Windows it uses the copy of the DB bundled with the OS and updated by the OS update mechanisms. On Windows, you have to install a PyPI module containing it. If Microsoft bundled it with the OS, with a C (not .Net) API, you wouldn’t have to do that-but Microsoft doesn’t, so you do
Re: Why are 2025/05/28 and 2025-05-28 different days in JavaScript?
#159Re: Why are 2025/05/28 and 2025-05-28 different days in JavaScript?
#160Earlier quoted context omitted.
I always felt the answer to this question is both, since there is always yesterday and tomorrow as far as lunch is concerned, so everything by definition is both before and after lunch. Perhaps the question is ill formed and needs to ask if the time was before, during or after lunch, during the day of the timestamp while defining what during means. That would have a more normal answer.
The question is clear. You are obfuscating it, for your own entertainment.
It is unclear to me. It has been ever since I was a child. This is what happens with periodicity. There is no 1 lunch reference point when you just say lunch in this sort of question.