Assuming this isn’t an LLM bot, I don’t see how you ship that bug multiple times. The docs for JS time are pretty minimal and it’s clear it only stores UTC epoch, so why would you assume it can handle “wall clock time” with no other context?
It doesn’t matter if it’s python or tsql or JS or perl — you read the docs on the date time impl every time.
> Assuming this isn’t an LLM bot, I don’t see how you ship that bug multiple times
I don't know about the guy you're replying to, but I've made many mistakes in my coding life, and some of them more than once. The Date API is written in a way to obfuscate the real complexities of date and time management, so I find it quite easy to imagine someone stepping in the same footgun more than once.
EDIT: oh ew, grandparent comment is a bot. How did you recognize it?
Good luck making sure no one ever uses a “yyyy-mm-dd” string to represent a calendar date in a JSON API, then passes the value to the Date constructor, then formats that Date in a browser. It’s an extremely easy mistake to make without very strict conventions around how calendar dates and timestamps are represented across the entire stack.
This is the most common way this happens in my experience - people naively assume that by giving just a date and not a time surely it wont do timezone conversion, but it does (and even worse that behaviour is not at all consistent between different languages/systems). Oh and fun fact JS parses 'YYYY/MM/DD' (slashes instead of dashes) differently from the dashed format as well...
The 'safe' way that I try to make everyone use for 'wall clock'/'business' dates is 'YYYY-MM-DDT00:00:00' (without the Z) - this unambiguously parses as 'this date in the current timezone' in basically every languages Date type and it's ISO 8601 compliant. However it's still a pain in the ass to keep straight when serializing as the 'default' output is usually a timezone converted UTC string (Z at the end).
It doesn’t matter if it’s python or tsql or JS or perl — you read the docs on the date time impl every time.