Comment by mnahkies

Comment by mnahkies 2 days ago

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.

JonChesterfield 2 days 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.

Reply View 2 replies

mnahkies 2 days 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.

Reply View | 1 reply
- masfuerte 2 days 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.]
  
  Reply View | 0 replies

alkonaut a day 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].

Reply View 0 replies

mattmanser 2 days 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.

Reply View 6 replies

NoInkling a day 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.

Reply View | 0 replies
kapep a day ago

> when timezones change, countries make changes to when their summer time starts, etc. Which happens all the time.
The frequency in which time zones are changed surprised me the first time I looked it up. For a single country it's probably quite a big deal that doesn't happen too often. But internationally there are several changes each year. I think it was like 4-6 changes per year in the past decades.

Reply View | 0 replies
josephg a day 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?

Reply View | 2 replies
- taylorlunt 18 hours ago
  
  Elixir handles all of this pretty well, for example differentiating between Date, Time, NaiveDateTime (a date and time), and DateTime (a date and time in a particular timezone). The Timex library is a great improvement too.
  JS has libraries that make the problem easier too. Though you'll never find a magic library that makes all the complexity disappear, because at the end of the day, you do need to tell the computer whether you mean 7 pm on the wall clock of where the users happen to be, 7 pm on a specific date in a specific time zone, etc. and doing math between dates is inherently complex with e.g. daylight savings changes. You might end up creating a datetime that doesn't exist (which Elixir handles well).
  
  Reply View | 0 replies
- dingi 19 hours ago
  
  Well, Java's date time APIs are pretty good if not best in the industry.
  
  Reply View | 0 replies
gpvos 2 days 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.

Reply View | 0 replies

samwho 2 days 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. :)

Reply View 0 replies

Hilift 2 days 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.

Reply View 0 replies

croes 2 days ago

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

Reply View 0 replies

lukan 2 days 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.

Reply View 8 replies

arp242 2 days 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.

Reply View | 0 replies
colonwqbang 2 days ago

A parser is supposed to reject invalid input, not generate semi-arbitrary outputs.

Reply View | 6 replies
- lukan 2 days 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.
  
  Reply View | 5 replies
  
  nilamo 2 days 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.
  
  Reply View | 4 replies