6 ms·
Why are 2025/05/28 and 2025-05-28 different days in JavaScript?
- mrweasel 1y agoDates in JavaScript is just a special kind of broken. Even with the more modern APIs for formatting dates it's just wonky at best.
- divan 1y agoWAT [1] [1] https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat
- hnbad 1y agoIt's a good talk but it's an even better talk if you actually like JS and understand not only why those things are the way they are but also that you wouldn't ever do them in normal code.
- divan 1y ago[flagged]
- poincaredisk 1y agoYou wouldn't do them intentionally, but they're there waiting to bite you in the foot.
- TZubiri 1y ago[flagged]
- deleted 1y ago[deleted]
- deleted 1y ago[deleted]
- LandR 1y agoJavascript delenda est!
- antisol 1y agoyep! Just imagine building websites using literally any other language. Sounds glorious, doesn't it?
- whatevaa 1y agoYup, brainfuck would be much better.
- fatata123 1y agoLike genital herpes, I am stuck with it. I might as well learn to like it. And eventually convert others across to the cause.
- TZubiri 1y agoRemember to disclose, I'm not a lawyer, but pretty sure it's criminal to spread without informing and getting consent. Your employer needs to know before you infect their codebase with react.
- lifthrasiir 1y agoAh, usual issues with any old enough language with multiple popular implementations. Enjoy your standards. (At least ECMAScript is a relatively well-thought standard...)
- bandrami 1y agoHow did they manage to build the entire modern Web on a language without a standard library?
- yen223 1y agoThe world where JavaScript has a robust standard library is one where there is only one browser vendor who gets to call all the shots regarding what the web looks like. That is not a better world.
- Y_Y 1y ago> That is not a better world. Not a better world, just the current world.
- aloha2436 1y agoSafari is too valuable of a platform for web developers to ignore, but otherwise yes it's the only real exception to the Chrome monopoly and still certainly much smaller in terms of absolute users.
- dotancohen 1y agoI use Firefox on all my devices.
- nomdep 1y agoMozilla is no longer a better actor than Google or Apple, just smaller
- cjpearson 1y agoPossibly, although the fix for this particular issue (Temporal API) is available in the current release of Firefox as well as the preview release of Safari, but it's not in that dominant browser.
- baq 1y ago
- Y_Y 1y agoHang on, slashes and year-month-day? https://en.wikipedia.org/wiki/ISO_8601 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.
- tluse 1y agoPro tip: never ever use anything but ISO dates in UTC tz unless you're displaying it for a user in a UI.
- ulrikrasmussen 1y agoAnd if you need a date, then represent it as a date and not as a time point.
- xiconfjs 1y agoEven then it‘s ok :)
- nssnsjsjsjs 1y agoAnd unless you need the original date, time and time zone. Conversion to UTC is not injective e.g. when clocks change or politics happen
- deleted 1y ago[deleted]
- fnord123 1y agoRFC3339. 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 them. RFC3339 is the way forward.
- vladde 1y agoIn Sweden, we can write dates as 28/5-25
- Philpax 1y agoEven more fun when that includes date or time ranges; I've literally had to paste Swedish-style dates into Claude to help me parse what the intended reading is.
- hnbad 1y agoI guess some people just want to see the world burn.
- 0points 1y agoAs 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.
- rf15 1y ago> YYYY-MM-DD as dictated by our excellent government 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! :)
- Lev1a 1y agoObligatory: https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat
- glkindlmann 1y agoThis was an informative (for me) explainer for what's happening in that video https://medium.com/dailyjs/the-why-behind-the-wat-an-explanation-of-javascripts-weird-type-system-83b92879a8db https://medium.com/dailyjs/the-why-behind-the-wat-an-explana...
- pif 1y agoUndocumented Undefined Behaviour, anyone?
- hnbad 1y agoIt's documented undefined behavior, really. Implementations are allowed to accept other input than ISO strings and interpret them how they like. The real "bug" in the example is 2025/05/28 being May 28th because the implementation ignores timezones for that format. The issue with `Date` is that it is based on the original `java.util.Date` class and inherits all of its problems: https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/Date.html https://docs.oracle.com/en/java/javase/21/docs/api/java.base... - this is also where the wonky zero-indexed month value comes from. Note that Java deprecated all versions of the constructor other than the one taking a millisecond value or nothing, which JS can't do for backwards compatibility reasons. Hopefully `Temporal` will solve these problems but how long that spec has been in the works should tell you how difficult this is to get right when anything you put on the web is forever.
- meekaaku 1y agohow about postgres style timestamp and timestamptz unless a timezone/offset is given, its considered plain date/time, not an epoch.
- hnbad 1y ago`Temporal` has three main types for this: - `Temporal.Instant` is a timestamp, the equivalent of a millisecond epoch timestamp or a UTC ISO string. - `Temporal.PlainDateTime` (and `Temporal.PlainTime`, `Temporal.PlainDate`, `Temporal.PlainYearMonth` and `Temporal.PlainMonthDay`) is timezone-unaware (i.e. they don't represent an actual point in time unless qualified with a timezone, e.g. when you just want to reference a calendar date). - `Temporal.ZonedDateTime` is timezone-aware (i.e. what you usually mean when dealing with specific instants in time). There's also `Temporal.Duration` which represents a delta between two instants and can be used to perform date manipulation (e.g. adding exactly one day or year to a given instant). I guess in terms of Postgress, `Temporal.ZonedDateTime` and `Temporal.PlainDateTime` are similar to `timestamptz` and `timestamp`, `Temporal.PlainDate` and `Temporal.PlainTime` are similar to `date` and `time` (without a timezone) and `Temporal.Duration` is similar to `interval`. It's odd that postgres allows for `time` to have a timezone but I guess that's only meant to be used when storing an instant as a set of `time` and `date` rather than a single `timestamptz`. `Temporal.PlainYearMonth` and `Temporal.PlainMonthDay` seem like the odd ones out but they make as much sense as `Temporal.PlainDate` if you want to reference specific calendar dates/months with incomplete information. I guess for sake of completeness one could argue for a need to be able to specify a precision for `Temporal.Time` to distinguish between a reference to "8 am", exactly "8:00", exactly "8:00.0" and so on, but that use case seems a lot more niche than those solved by the additional date types.
- Havoc 1y agoNo idea but it makes perfect sense that the question is about JavaScript
- deleted 1y ago[deleted]
- PokerFacowaty 1y agoI 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 midnight of UTC+2 as the time, they were all a day behind in UTC. Special shoutouts to the author of node-postgres saying the PG's date type is better not used for dates in this case.[1] I love programming. [1] https://node-postgres.com/features/types#date--timestamp--timestamptz https://node-postgres.com/features/types#date--timestamp--ti...
- normie3000 1y ago> 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).
- dumah 1y agoISO 8601-1:2019/Amd 1:2022 Midnight at the start of the day: 00:00:00 Midnight at the end of the day: 24:00:00
- kccqzy 1y agoIndeed it is not sane. Languages should provide a separate Day type to operate on dates without times. Forcing everything to use dates with times and timezones causes bugs in applications that don't need times.
- animanoir 1y agoI wish we could move on from this trash already.
- pif 1y agoI'm missing the usual suspects complaining about how browsers exploit undefined behaviour and break programmers' expectations.
- alex-knyaz 1y agoWhat are best practices/tips on handling date and time everyone has in general? Every time it is a bit of a nightmare.
- happytoexplain 1y agoThe best advice is unfortunately to not use a generalized practice. E.g. never "just use UTC". Use UTC when it makes sense. - Understand the semantic difference between a timestamp (absolute time) and clock/calendar time (relative time). Understand which one your use case uses. Don't use one to store the other. - If the use case calls for a relative time, do not manually construct or edit the date. Use your platforms date-creation/modification APIs, no matter how unnecessary they seem. - Understand what is inside your platform's date types at rest. Understand which of your platform's date APIs pull in environmental information (time/tz/locale), as opposed to only using the arguments you pass it. Understand that your platform's 'print/stringify' function may be one of those aforementioned functions. Misunderstanding this often leads people to say inaccurate things. E.g. say your platform has a Date object that stores an epoch-based timestamp. People may say "the Date object is always in UTC", when really the Date object has no time offset, which is not the same thing. - Understand that if you pass a date around platforms, it might accidentally be reserialized into the same absolute time, but a different relative time. - Understand that there is a hierarchy of use cases, where each one has more complex requirements: 1. "Create/modify" timestamps; egg timers. (absolute time) 2. Alarm clocks (same clock time always). 3. One-time calendar events (has an explicit, static tz; same clock time if the user changes its day or time zone; different clock time if the user's time offset changes) 4. Recurring calendar events (same as above, except don't change the clock time if the user's time offset changed due to DST, as opposed to a geographic change) 5. Recurring calendar event with multiple participants (same as above, just remember that the attached tz is based on the creator, so the clock time will shift during DST for participants in a place without matching DST rules). Note that a lot of platforms nowadays have built-in or 3rd party packages that automatically handle a lot of the rules in the above use cases. Finally, understand that all those little weird things about dates (weird time zones, weird formatting conventions, legislative time zone changes, retroactive legislative time zone changes, leap days, leap seconds, times that don't exist), are good to know, but they will mostly be accounted for by the above understandings. You can get into them when you want to handle the real edge cases.
- thrdbndndn 1y agoAfter carefully reading the timeline, I think the most surprising part is that when Chrome switched again to defaulting to local time for date-only forms in 2015 (together with date-time form), someone complained it was a "breaking change", despite the fact that it was simply following the spec, and it even went so far that it eventually caused the spec itself to change, and now we’re stuck with the Frankenstein mess we have today. By that, I don't mean to dismiss the importance of backward compatibility, but this case is particularly funny because: 1. It had already been changed multiple times, each a breaking change, so it’s not like this form of compatibility was ever seriously respected; 2. Having it behave differently from other "legacy forms," like the slash-separated version, is itself arguably a break in backward compatibility; 3. As noted in the article, it never worked the same between Chrome and Firefox (at this point) anyway, so it’s doubtful how impactful this "breaking change" really was, considering you already had to write shim code either way.
- nordiknomad5 1y agoI 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
- dust42 1y agoIf your local timezone is GMT>=0, then you wont see it. A special form of a Heisenbug that you only see easily when located in the Americas, while when in Europe/Africa/Asia it is invisible unless you switch your local time zone to any GMT-X value.
- nordiknomad5 1y agook thanks for the clarification :)
- stevoski 1y agoI find it fascinating that JavaScript has so many "WTF?" things like this, and yet is so incredibly successful. Being available everywhere (as far as browsers are concerned) trumps almost all other factors.
- dotancohen 1y agoPhotographers have a saying: The best camera in the world, is the camera you have on you.
- antisol 1y ago[flagged]
- fimdomeio 1y agoOn a broader note for the ones out there not familiar with this "timeless" classic: Falsehoods programmers believe about time gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca
- HenryBemis 1y ago2020-04-23 16:36 is the date and time (as listed in my Bookmark Manager) that I bookmarked this [0] to my Firefox browser. [0]: https://xkcd.com/1179/ https://xkcd.com/1179/