4 ms·

It's a fun quiz, and there's a lot of surprising behaviour. However in my opinion from a practical perspective it mostly doesn't matter. Think hard about wheth

It's a fun quiz, and there's a lot of surprising behaviour. However in my opinion from a practical perspective it mostly doesn't matter. Think hard about whether your use case really cares about local time, try and find ways to make instants appropriate. Then stick to UTC ISO 8601 strings / Unix timestamps and most of the complexity goes away, or at least gets contained to a small part of your software. I know this isn't always possible (I once had to support a feature that required the user took a break covering two periods of 1-5am local, which was obviously fun around DST boundaries) - but in my experience at least the majority of the time you can find ways to minimise the surface area that cares. If you're passing raw/unvalidated user input to the date parser you're holding it wrong.

samwho 1y ago
I agree with this. I do think it’s an easy trap to fall into if you’re unfamiliar, and hopefully this quiz has made a whole wave of folks more familiar. :)
lukan 1y ago
"If you're passing raw/unvalidated user input to the date parser you're holding it wrong." Exactly. I would have never thought about using the Date class in this way. So the behavior is pretty much wtf and local time can get pretty complicated, but I wouldn't expect to get the right time, when passing some vague strings.
- colonwqbang 1y ago
  A parser is supposed to reject invalid input, not generate semi-arbitrary outputs.
  - lukan 1y ago
    I agree on a theoretical level, but this is javascript and the web we are talking about. Invalid input is rather the norm in genereral, with the expectation the browser should still display something. But I do dream of a alternative timeline, in where the web evolved different.
    - nilamo 1y ago
      Let's say you're setting an appointment. The user puts in nonsense, so you helpfully schedule an appointment for a nonsense date (thank you so much, we'll get right to that in -124 years). Instead of... catching a parsing error and asking the user to try again or something? It's wild that a nonsense date would be considered for any purpose at all in a user-centric system.
      - lukan 1y ago
        If you really ask me, I don't build forms that accept strings as dates from users. There is a date picker element, that can be restricted and validated.
        giantrobot 1y ago
        You still need to do some validation of the input because it's difficult to impossible (in many cases) to be absolutely sure the input you receive only comes from your validated form. Even code running entirely within the browser can receive broken/malicious input from an extension, user script, or even the host OS. It can be a bit belt and suspenders doing validation of specific forms but shit happens. It's much better to catch stuff before it's persisted on the back end or on disk.
        lukan 1y ago
        That's why I wrote, "validated" And there can also be man in the middle attacks or whatever, the efforts you do for validation depends still on your task at hand. How critical an error would be. But even for the most trivial tasks I would never think of passing some user strings to Date and expect to get a valid value.
      - hombre_fatal 1y ago
        Then again, I don’t think you pass user input directly into a date constructor in any language, in practice. You decide on the format that makes sense for the user, you validate the input against that format, and then you map it into a native date. If the date constructor supports the format you want, it’s only coincidence that makes that final mapping step simpler. So, the native date constructor having weird behavior on invalid strings doesn’t really change real world code.
- arp242 1y ago
  The entire point of a parser is to parse unknown values. That's the entire job of a parser: take unstructured (usually string) data and turn it in to something structured, such as a date. If it can't do that reliably with error reporting then it's not a good parser on a very fundamental level. There are so many valid and reasonable cases where this will bite you. "Real-world data" from CSV files or XML files or whatnot (that you don't control) and sometimes they have errors in them, and it's useful to know when instead of importing wrong data. You do something wrong by mistake and getting wrong/confusing behaviour that you literally never want, and then you need to debug where that's coming from. The user gives you a date, you have no idea what they entered and you want to know if that's correct.
JonChesterfield 1y ago
Given that the right way to turn user input into validated input is to _parse_ it, passing it to the language feature called the _date parser_ is a completely reasonable thing to do. That this doesn't work probably doesn't surprise javascript programmers much.
- mnahkies 1y ago
  Yeah this is a fair take - I guess my unwritten stipulation was don't expect anything from the JavaScript standard library to behave as you'd expect, outside of fairly narrow paths. TBH even when working with other languages I'd skew towards doing this, possibly because I've worked with JavaScript/TypeScript too much. It's a balance but there's a certain comfort in making constraints really explicit in code you control over blindly trusting the standard library to keep it's behaviour over the lifetime of the product.
  - masfuerte 1y ago
    It's not just JS. I'm familiar with a language interpreter that used C++ stream I/O for parsing numbers. When C++ expanded the syntax for numbers it broke the interpreter in some cases. This isn't too bad if you catch it quickly but if people start relying on the new, undocumented feature it can be impossible to fix without upsetting someone. [Small edits for clarity.]
Hilift 1y ago
I agree, and/or give an option to specify the DST offset. That is sometimes useful. I was always confused that Excel did not infer the format when using CSV's though.
croes 1y ago
Good luck with a random dependency or dependency of a dependency that doesn’t work that way.
mattmanser 1y ago
Every time someone says "just stick to UTC ISO 8601 strings / Unix timestamp", it's clear they've only worked with dates in very specific ways. Try that tactic with FUTURE dates. Meet at 7pm still means meet at 7pm when timezones change, countries make changes to when their summer time starts, etc. Which happens all the time. And it's actually a more subtle problem. You actually need the context of the timezone in some applications. If your application is showing dinner reservations, for example, you want to display the time in the local time of the restaurant, not the local time of the user. You want to know when it's booked THERE, not where you happen to be right now. I want to know my booking is at 7pm, not 1pm because I happen to be in America right now. So using GMT/UTC is not a panacea for all the date problems you face. It's only a solution for dates in the past. And even then you might argue that sometimes it's worth also storing the local time of the user/thing the event happened to, or at the very least the timezone they were in when it happened in a separate field.
- gpvos 1y ago
  > you want to display the time in the local time of the restaurant Many European railway timetable amd booking websites fall foul of this.
- NoInkling 1y ago
  The IANA timezone database does occasionally revise historical rules when relevant information comes to light. So you might have calculated that some historical figure died at such-and-such a time UTC (based on a documented local time), but actually that's inaccurate and you might not know because you haven't redone the calculation with the new rules.
- josephg 1y ago
  Are any other languages more sane with this stuff? Because I've also been to this particular corner of hell. Also in a web app. But - wouldn't this be just as horrible in Go or Rust or any other language? (Or god forbid, C?) Are there better timezone APIs in other languages than what you can find in NPM that make these problems any easier to deal with?
  - 1y ago
alkonaut 1y ago
> If you're passing raw/unvalidated user input to the date parser you're holding it wrong. Oh absolutely. But the difference between a sane api and other APIs is that a sane one will fail in a sane way, ideally telling me I’m holding it wrong. Especially: the key at every turn is to fail hard if there is anything even slightly wrong rather than do something potentially incorrect. Many JS apis seem designed to continue at any cost which is the fundamental problem. You never really want a NaN. You don’t want to coerce strings to [whatever].

samwho 1y ago

I agree with this. I do think it’s an easy trap to fall into if you’re unfamiliar, and hopefully this quiz has made a whole wave of folks more familiar. :)

lukan 1y ago

"If you're passing raw/unvalidated user input to the date parser you're holding it wrong." Exactly. I would have never thought about using the Date class in this way. So the behavior is pretty much wtf and local time can get pretty complicated, but I wouldn't expect to get the right time, when passing some vague strings.

colonwqbang 1y ago
A parser is supposed to reject invalid input, not generate semi-arbitrary outputs.
- lukan 1y ago
  I agree on a theoretical level, but this is javascript and the web we are talking about. Invalid input is rather the norm in genereral, with the expectation the browser should still display something. But I do dream of a alternative timeline, in where the web evolved different.
  - nilamo 1y ago
    Let's say you're setting an appointment. The user puts in nonsense, so you helpfully schedule an appointment for a nonsense date (thank you so much, we'll get right to that in -124 years). Instead of... catching a parsing error and asking the user to try again or something? It's wild that a nonsense date would be considered for any purpose at all in a user-centric system.
    - lukan 1y ago
      If you really ask me, I don't build forms that accept strings as dates from users. There is a date picker element, that can be restricted and validated.
      - giantrobot 1y ago
        You still need to do some validation of the input because it's difficult to impossible (in many cases) to be absolutely sure the input you receive only comes from your validated form. Even code running entirely within the browser can receive broken/malicious input from an extension, user script, or even the host OS. It can be a bit belt and suspenders doing validation of specific forms but shit happens. It's much better to catch stuff before it's persisted on the back end or on disk.
        lukan 1y ago
        That's why I wrote, "validated" And there can also be man in the middle attacks or whatever, the efforts you do for validation depends still on your task at hand. How critical an error would be. But even for the most trivial tasks I would never think of passing some user strings to Date and expect to get a valid value.
    - hombre_fatal 1y ago
      Then again, I don’t think you pass user input directly into a date constructor in any language, in practice. You decide on the format that makes sense for the user, you validate the input against that format, and then you map it into a native date. If the date constructor supports the format you want, it’s only coincidence that makes that final mapping step simpler. So, the native date constructor having weird behavior on invalid strings doesn’t really change real world code.
arp242 1y ago
The entire point of a parser is to parse unknown values. That's the entire job of a parser: take unstructured (usually string) data and turn it in to something structured, such as a date. If it can't do that reliably with error reporting then it's not a good parser on a very fundamental level. There are so many valid and reasonable cases where this will bite you. "Real-world data" from CSV files or XML files or whatnot (that you don't control) and sometimes they have errors in them, and it's useful to know when instead of importing wrong data. You do something wrong by mistake and getting wrong/confusing behaviour that you literally never want, and then you need to debug where that's coming from. The user gives you a date, you have no idea what they entered and you want to know if that's correct.

JonChesterfield 1y ago

Given that the right way to turn user input into validated input is to _parse_ it, passing it to the language feature called the _date parser_ is a completely reasonable thing to do. That this doesn't work probably doesn't surprise javascript programmers much.

mnahkies 1y ago
Yeah this is a fair take - I guess my unwritten stipulation was don't expect anything from the JavaScript standard library to behave as you'd expect, outside of fairly narrow paths. TBH even when working with other languages I'd skew towards doing this, possibly because I've worked with JavaScript/TypeScript too much. It's a balance but there's a certain comfort in making constraints really explicit in code you control over blindly trusting the standard library to keep it's behaviour over the lifetime of the product.
- masfuerte 1y ago
  It's not just JS. I'm familiar with a language interpreter that used C++ stream I/O for parsing numbers. When C++ expanded the syntax for numbers it broke the interpreter in some cases. This isn't too bad if you catch it quickly but if people start relying on the new, undocumented feature it can be impossible to fix without upsetting someone. [Small edits for clarity.]

Hilift 1y ago

I agree, and/or give an option to specify the DST offset. That is sometimes useful. I was always confused that Excel did not infer the format when using CSV's though.

croes 1y ago

Good luck with a random dependency or dependency of a dependency that doesn’t work that way.

mattmanser 1y ago

Every time someone says "just stick to UTC ISO 8601 strings / Unix timestamp", it's clear they've only worked with dates in very specific ways. Try that tactic with FUTURE dates. Meet at 7pm still means meet at 7pm when timezones change, countries make changes to when their summer time starts, etc. Which happens all the time. And it's actually a more subtle problem. You actually need the context of the timezone in some applications. If your application is showing dinner reservations, for example, you want to display the time in the local time of the restaurant, not the local time of the user. You want to know when it's booked THERE, not where you happen to be right now. I want to know my booking is at 7pm, not 1pm because I happen to be in America right now. So using GMT/UTC is not a panacea for all the date problems you face. It's only a solution for dates in the past. And even then you might argue that sometimes it's worth also storing the local time of the user/thing the event happened to, or at the very least the timezone they were in when it happened in a separate field.

gpvos 1y ago
> you want to display the time in the local time of the restaurant Many European railway timetable amd booking websites fall foul of this.
NoInkling 1y ago
The IANA timezone database does occasionally revise historical rules when relevant information comes to light. So you might have calculated that some historical figure died at such-and-such a time UTC (based on a documented local time), but actually that's inaccurate and you might not know because you haven't redone the calculation with the new rules.
josephg 1y ago
Are any other languages more sane with this stuff? Because I've also been to this particular corner of hell. Also in a web app. But - wouldn't this be just as horrible in Go or Rust or any other language? (Or god forbid, C?) Are there better timezone APIs in other languages than what you can find in NPM that make these problems any easier to deal with?
- 1y ago

alkonaut 1y ago

> If you're passing raw/unvalidated user input to the date parser you're holding it wrong. Oh absolutely. But the difference between a sane api and other APIs is that a sane one will fail in a sane way, ideally telling me I’m holding it wrong. Especially: the key at every turn is to fail hard if there is anything even slightly wrong rather than do something potentially incorrect. Many JS apis seem designed to continue at any cost which is the fundamental problem. You never really want a NaN. You don’t want to coerce strings to [whatever].