JavaScript decided my day starts at 9am(senhongo.com)
senhongo.com
JavaScript decided my day starts at 9am
https://senhongo.com/blog/when-javaScript-decided-my-day-starts-at-9am
46 comments
I just want to display the last updated time in the corner of a blog post. Overwriting local innerText with JavaScript for that is nonsense.
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.
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.
> 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.
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.
> 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.
I am sure the "as a user, I should see relative timestamps" ticket was closed fast though! Another job well done!
So it does not take the year into consideration? Well damn.
Thanks for the context, it felt really weird to see such a "rookie" bug on the front page of HN :)
(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.
(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.
Nothing wrong with this. Operating in one timezone only simplifies things, no need to overcomplicate it.
Obvious potential failure case: Japanese citizens who are travelling abroad.
Many Japanese studying abroad use VPNs in order to circumvent services blocking overseas traffic.
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.
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.
Using a VPN doesn't change your time zone
Following this logic, python 3 needn’t have been created.
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.
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.
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 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.
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.
The issue here is that timezone are often handled like an environment setting instead of as an element of the day-time-timezone tuple
I use Google for some things.
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).
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've used the default Calendar app on my iDevices since forever and it has always done the timezone conversions auto-magically for me. The only extra bit of work I have to do is convert the date to my local time zone during input.
Author here.
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.
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 think developers need to clearly understand this and then make reasonable (ideally also visible) choices for the reference frame used in the frontend.
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.
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.
[deleted]
From the post:
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.
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.
There is no ambiguity. The Date constructor provides a timezone offset:
myDate.getTimezonOffset();
>> I think a better "lesson learned" in this case is to remove all ambiguity from datetime types ...
> 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:
> 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 ...
I've only just realised people mean UTC0 when they say store/use dates in UTC. For some reason, I've always thought it meant storing it in the ISO format. YYYY-MM-DD HH:mm:ss.sssZ which I've always done.
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
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
Adding to this, if you are dealing with dates in JavaScript specifically I recommend going further and doing all business logic with the UTC timestamp stored as a number / unix epoch, and only doing `new Date(timestamp)` when you need it in local time, like right before rendering on the page or something as you mentioned.
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.
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.
I was thinking like that before, however now I think it's overkill. Millisecond timestamps are hard to read, they are stored as "bigint" in Postgres, which makes it sometimes annoying. What I prefer now is to use the date object, but remember that it's only UTC (and the machine where the code runs should be in UTC time too). It goes well with Postgres Timestamp+TZ field, and it's much more readable.
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.
The user doesn't care about the timezone change yesterday (and shouldn't..), they just need to see their meeting at 10am.
It is a good carve out, but it means you have to be careful.
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.
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.
It's just not DST though. What if the user moves to a different country? Their 10am US meeting should probably update to the local timezone.
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.
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.
When dealing with timestamps, it's easiest to store and process them in UTC for as much of your code as possible. This means pretty much all of your backend and database code. Only convert these values from UTC to other timezones when presenting this data to the user (at that point, you'd need to take the user's timezone(s) into account).
in general, backend life becomes way, way easier if you just store everything in zulu time, transmit in zulu, and localize it on the frontend (which is what javascript does by default anyhow, iirc).
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.
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.
[deleted]
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);
valueAsDate: ”The date returned should always be interpreted as a UTC time”
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.
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.
Ah, dang it! Thanks! Now that I read it, even *-local ones won’t do what I thought they did? valueAsDate isn’t a thing there. Wish I could unvote myself or that comment. Note to self: never comment on HN when you’re groggy and on a phone and never trust Date APIs lol.
Can’t wait for Temporal to get here which hopefully irons these out better.
Can’t wait for Temporal to get here which hopefully irons these out better.
Ever-relevant Tom Scott descent into madness
https://youtu.be/-5wpm-gesOY?si=8HtG8fFeWbdeM4xh
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.
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.
> 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.
Or 9 days, depending on the time zone you're in
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?
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.