It obviously depends on your use case but I find most time operations are often easier to deal with as pure mathematical operations. I will reach for Date when I need to deal with weird stuff like the day of the week but having burned through so many footguns with what I consider the worst DateTime API I have ever dealt with in any language, I will do anything I can to avoid using it.
Some libraries like date-fns can help here, but can't always bring in new deps easily. I hope the new temporal API fixes things.
The user doesn't care about the timezone change yesterday (and shouldn't..), they just need to see their meeting at 10am.
For example, in my work, we handle appointment data, and we've gotten appointments sent to us from an upstream provider scheduled for non-existent local timestamps. (E.g., 2:30am in the middle of a spring-forward jump. That timestamp doesn't exist. Also in the fallback, where that timestamp is ambiguous.)
Even Google Calendar chokes on certain appointment times.
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.
I have been in a paper-notebook-calendar mode for a while now, but every time I've dealt with an electronic calendar app, it's been a struggle, because sometimes I write down a time relative to the time zone I'm in right now, and sometimes I write down a time relative to the TZ I'll be in when the thing happens (on vacation, at a conference, whatever). And for things in the latter category, I _want_ to visibly see the local-to-the-event time so that I can talk to other people about it, but I also want it to be in the correct time when I'm actually at the event so that I don't miss an appointment. This is trivially easy on a paper calendar I keep for myself and is Really Dang Tricky for electronic calendar apps.
One of the things you can do with Google calendar is have multiple timezones listed on your calendar. This way, it's easy to see when the even is regardless of what time zone is the source of reference. It's a lifesaver.
Note: This seems to work on Google Calendar web, but I can't find a way to do this with the mobile app (Android).
For example the last application I worked on used UTC everywhere in the backend, database, APIs etc and stored a timezone configuration per account. The frontend used that timezone when displaying any date/time and also for parsing user date inputs. With a few places having a timezone drop down next to an input in places where it made business sense for the user to mean an explicit timezone.
As mentioned elsewhere, Japanese SaaS rarely ever deal with timezones because there's only 1 timezone. And I think this was originally built this way (using YYYY-MM-DD for filtering) to avoid having to think about time zones, with the assumption that the YMD values were all that mattered.
In our instance, it doesn't matter where the dashboard is used. It's a service built in Japan for people living in Japan. The dates are stored in Japan Standard Time in the database, so even when the dashboard is accessed from outside Japan, the user is only interested in filtering the values based on Japanese dates.
Otherwise, I agree with you.
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.
Displaying relative time like “1 day ago” is especially foolish. Does that mean between 0s–23:59:59? Or 24:00:00–47:59:59? Or perhaps 24:00:00–6d 23:59:59?
When you have multiple browser tabs open and switch between them, and you see “just now” — is it really just now? You last looked at that tab an hour ago. Maybe two hours? Maybe it’s been open since yesterday.
Sometimes I wonder why the Accept-Timezone header doesn’t exist in web browser requests. Using Accept-Language to switch webpage language based on the same URL is now commonplace.
There would likely be demand for a feature where the <html> contains a Unix timestamp, and the browser renders it using the client’s local time zone:
<time epochMs="1234567890123" format="YYYY/MM/DD HH:mm:ss" />
Just write it into static HTML and you’re done. No need for the server to compute relative times, and no need to rewrite it dynamically with JavaScript.
What happened to the movement to abolish daylight saving time? A few years ago, I kept hearing that the US and EU were moving toward ending it. Yet here we are, still observing DST this year.
> When you have multiple browser tabs open and switch between them, and you see “just now” — is it really just now? You last looked at that tab an hour ago. Maybe two hours? Maybe it’s been open since yesterday.
I have a screenshot of two Jira comments that go from "one year ago" to "one hour ago" because the two comments happened to be something like Dec 31 and Jan 2.
Most businesses do not care, because it's harder to counter bots when allowing overseas traffic. Moreover, the number of Japanese who leave the country are a small fraction. For reference, the percentage of Japanese who hold a passport is 17%. A small fraction of the 17% represent students studying abroad (or other long-term stays).
There's enough internal demand that people travelling abroad (or studying abroad) are considered edge cases worth ignoring. As surreal as this sounds, this is the current situation.
(And I mean "rookie" in the "young an innocent sense" - I vividly remember the day I was asked to displayed timestamped data for IoT devices in both local times of the machine and the user. "Yeah, should take half the day" was my answer. Ooooh to be naive again...)
I suppose the sentiment must be the same as i18n for the USA ("what do you mean there are _other_ languages ? Oh, you mean Spanish ?"), unit systems for Continental Europeans ("what do you mean 'Imperial system' is still a thing ?), and currencies for everyone ("what do you mean 0.1 + 0.2 != 0.3 ?")
It comforts me (a bit) to think that our robot overlords will inherit all this complexity (by virtue of being created by us), and it might make their revolt slightly less effective.
const el = /* get handle to date element */
const d = el.valueAsDate;
d.setHours(0, 0, 0, 0);
The setHours trick will probably not work as expected if the user is on a timezone with a positive UTC offset.
They select a date in their local time, but in UTC, the date is still the previous day’s date!
So when user selects 2025-07-30 in +09:00, the UTC datetime will be set to 2025-07-29T15:00:00Z. setHours will then make it 2025-07-29T00:00:00Z, the date part of which would be rendered in local time as 2025-07-29, a full day off from what the user intended.
Can’t wait for Temporal to get here which hopefully irons these out better.
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.
myDate.getTimezonOffset();
> There is no ambiguity.
The ambiguity I referenced was regarding program logic, not how `Date` operates when given only the year/month/date part of an instant. Perhaps I should have said instead:
I think a better "lesson learned" in this case is to
remove all ambiguity when using datetime types
by internally using only UTC representations for
calculations ...
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
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.
maybe there are some cases where you want to store the timezone (e.g. you've displayed a datepicker and the user has expressly entered a timezone)--but normally you'll save headache by storing everything in zulu time.
if storing the timezone is important for those transactions, then I could potentially see that as warranting storage with a timezone as well.
basically, ask 'if the timezone matters' with respect to the information being encoded. if it's just for display purposes and can be ignored, then KISS.
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.
kayodelycaon•20h ago
> 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.
croemer•14h ago