11–20 of 47 posts
My rule of thumb is: keep all business logic in UTC, and convert from/to local time as close to the UI as possible
The user doesn't care about the timezone change yesterday (and shouldn't..), they just need to see their meeting at 10am.
const el = /* get handle to date element */
const d = el.valueAsDate;
d.setHours(0, 0, 0, 0);
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 t…
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 contains a Unix timestamp, and the browser renders it using the client’s local time zone:
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.
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 implici…
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.
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 implici…
It's worse than this: it's not just "what's my (app developer) reference frame for time in this app" but rather "what is the user's reference frame", and that is a thing that changes even for a single user. 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 i…
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).
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.
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
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. This is all the Date constructor could do in this use-case. There is no timezone specified and assuming one other than UTC could easily result in undefined behavior. I think a better "lesson learned" in this case is to remove all ambiguity from datetime types by internally using only…
myDate.getTimezonOffset();
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 have always followed the same, but also found calendar events are a good carve out to this. 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.
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 t…