Since Japan has exactly one timezone and most services are intended for use within Japan, many Japanese programmers are unaware of timezone-related logic. I've frequently encountered Japanese sites store dates as OffsetDateTime instances (rather than UTC Instants), and have frequently seen subtle bugs, like a web app's backend returning UTC+9 timestamps, and then subsets of the frontend format the date according to the user's local time. I witnessed this last week on a fairly big concert ticket website. The lottery application datetime was simply formatting the OffsetDateTime returned by backend. Then, for some reason, the lottery result announcement datetime was being passed through a different formatting function. Two adjacent timestamps were in different timezones and there were no visual indications of this. I learned a lot about the site's API when investigating. I later reported the bug and was told the service is not intended for use outside of Japan, so they won't fix.

I've also encountered games where device local time results in bugs when certain features are gated to durations within Japanese Standard Time. For one particular game, I contacted support and the response was similarly "this service is intended for use within Japan; please ensure your device time is set to Japanese Standard Time." The support representative actually went further and told me, "if you are using this service outside of Japan, then we cannot make any guarantees on [the app's] behavior or resolve issues."

To most programmers in the US or Europe, storing all dates as UTC and localizing datetimes in the frontend may seem like "common sense", but this is essentially 異文化 to many Japanese programmers, for lack of a better way to phrase it.

There's a larger design issue here that becomes clearer if you think of timezones as something more like temporal reference frames. Every date and/or time is relative to something; it's just a question of whether that reference is explicit or implicit, and if it's implicit then how does it get resolved?

Your original code (inadvertently) used a UTC day: T00:00:00Z -> T24:00:00Z. Your new code uses a day in an implicit timezone, which gets resolved by the client (to its local time). So, if you send that dashboard to someone in Singapore or Australia, their day is going to be an hour off compared to what you see.

Ultimately, the design issue is: when someone says "Tuesday", do they mean Tuesday in their local time? Tuesday in Japan? Tuesday in the location of their company HQ? Tuesday in the timezone where they do the most business?

I think a lot of the reason people get mad about timezones is because they don't think clearly about their reference frames from the beginning, which leads to getting caught up in implicit time spaghetti later on.

From the post:

  I knew that new Date('YYYY-MM-DD') sets the time to 
  midnight. What I didn’t know was that it sets it to 
  midnight in UTC.

I think a better "lesson learned" in this case is to remove all ambiguity from datetime types by internally using only UTC representations for calculations and reserve timezone usage for display purposes.

Unless this is the absolute only place that's using dates/times it's worth bringing in a library for this. The built in Date class is miserable. Also see the new Temporal proposal https://github.com/tc39/proposal-temporal

Related:

Why are 2025/05/28 and 2025-05-28 different days in JavaScript? (144 points, 2 months ago, 153 comments) https://news.ycombinator.com/item?id=44113397

New Date("wtf") – How well do you know JavaScript's Date class? (409 points, 18 days ago, 236 comments) https://news.ycombinator.com/item?id=44540241

If you always store dates as unix seconds and display them as local time on the browser, you'll almost never go wrong. Most other strategies leave too much room for ambiguity.

My rule of thumb is: keep all business logic in UTC, and convert from/to local time as close to the UI as possible

I'm building a fairly large SaaS product that will have global users and show financial reporting across different regions. Nothing gives me more anxiety as a relatively new developer than storing and recalling date/time values from my Postgres database, being converted to/from/being displayed in my app.

I have all records stored in timestampz(3), but I have no idea if what I'm doing is best practice or how to audit said functions. Using luxon at the moment, but a guide or blog post for best practices would help put my mind at ease if anyone has one. I know dates as a library are complex, but the UX managing them isn't much better.

undefined

Better way to set this from input type=“date”:

    const el = /* get handle to date element */
    const d = el.valueAsDate;
    d.setHours(0, 0, 0, 0);

Ever-relevant Tom Scott descent into madness

https://youtu.be/-5wpm-gesOY?si=8HtG8fFeWbdeM4xh

Your first mistake is using Javascript's Date.

Js Joda is the only datetime library that doesn't make me wanna cry -> https://js-joda.github.io/js-joda/

It is kinda similar to the new Temporal api: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Or if you want to live on the edge: https://www.npmjs.com/package/temporal-polyfill

For experiments, I would strongly suggest to look into Temporal API.

From MDN:

> When the time zone offset is absent, date-only forms are interpreted as a UTC time and date-time forms are interpreted as a local time

Fun!

Obligatory joke:

Brendan Eich created JavaScript in 10 days. And we’ve been fixing it ever since.

I remember using JavaScript when building websites.

utc is the way and never trusting client side time, granted this could be server side time i guess

What are unit tests?