5 ms·

JavaScript decided my day starts at 9am

34 points by SenHeng 1y ago

kayodelycaon 1y ago
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.
- croemer 1y ago
  Or 9 days, depending on the time zone you're in
svachalek 1y ago
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 https://github.com/tc39/proposal-temporal
hatthew 1y ago
My rule of thumb is: keep all business logic in UTC, and convert from/to local time as close to the UI as possible
- yesco 1y ago
  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.
  - TheRoque 1y ago
    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.
- rrrhys 1y ago
  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.
  - deathanatos 1y ago
    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.
  - rjh29 1y ago
    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.
jahrichie 1y ago
utc is the way and never trusting client side time, granted this could be server side time i guess
xyzzy9563 1y ago
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.
jedimastert 1y ago
Ever-relevant Tom Scott descent into madness https://youtu.be/-5wpm-gesOY?si=8HtG8fFeWbdeM4xh https://youtu.be/-5wpm-gesOY?si=8HtG8fFeWbdeM4xh
sgentle 1y ago
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.
- blahedo 1y ago
  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.
  - esseph 1y ago
    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).
koito17 1y ago
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.
- fushihara 1y ago
  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.
sangeeth96 1y ago
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); I wonder why there’s no date-local like there’s datetime-local given this gotcha: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/input/datetime-local https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
- cluckindan 1y ago
  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.
  - sangeeth96 1y ago
    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.
AdieuToLogic 1y ago
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 UTC representations for calculations and reserve timezone usage for display purposes.
- austin-cheney 1y ago
  There is no ambiguity. The Date constructor provides a timezone offset: myDate.getTimezonOffset(); It outputs the number of minutes different from UTC time. I use this to display server time in both server local and zulu (UTC) via a WebSocket broadcast every 950ms.
  - AdieuToLogic 1y ago
    >> 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: 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 ... And, yes, I do see the irony in this. :-)
- SenHeng 1y ago
  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.
gnabgib 1y ago
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 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 https://news.ycombinator.com/item?id=44540241
CuriousRose 1y ago
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.
- jpalawaga 1y ago
  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.
- petersellers 1y ago
  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).
Traubenfuchs 1y ago
What are unit tests?
deleted 1y ago
[deleted]
mediumsmart 1y ago
I remember using JavaScript when building websites.
tobyhinloopen 1y ago
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/ 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/Reference/Global_Objects/Temporal 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 https://www.npmjs.com/package/temporal-polyfill For experiments, I would strongly suggest to look into Temporal API.

34 points by SenHeng 1y ago

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.

croemer 1y ago
Or 9 days, depending on the time zone you're in

svachalek 1y ago

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 https://github.com/tc39/proposal-temporal

hatthew 1y ago

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

yesco 1y ago
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.
- TheRoque 1y ago
  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.
rrrhys 1y ago
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.
- deathanatos 1y ago
  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.
- rjh29 1y ago
  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.

jahrichie 1y ago

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

xyzzy9563 1y ago

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.

jedimastert 1y ago

Ever-relevant Tom Scott descent into madness https://youtu.be/-5wpm-gesOY?si=8HtG8fFeWbdeM4xh https://youtu.be/-5wpm-gesOY?si=8HtG8fFeWbdeM4xh

sgentle 1y ago

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.

blahedo 1y ago
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.
- esseph 1y ago
  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).

koito17 1y ago

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.

fushihara 1y ago
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.

sangeeth96 1y ago

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); I wonder why there’s no date-local like there’s datetime-local given this gotcha: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/input/datetime-local https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

cluckindan 1y ago
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.
- sangeeth96 1y ago
  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.

AdieuToLogic 1y ago

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 UTC representations for calculations and reserve timezone usage for display purposes.

austin-cheney 1y ago
There is no ambiguity. The Date constructor provides a timezone offset: myDate.getTimezonOffset(); It outputs the number of minutes different from UTC time. I use this to display server time in both server local and zulu (UTC) via a WebSocket broadcast every 950ms.
- AdieuToLogic 1y ago
  >> 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: 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 ... And, yes, I do see the irony in this. :-)
SenHeng 1y ago
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.

gnabgib 1y ago

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 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 https://news.ycombinator.com/item?id=44540241

CuriousRose 1y ago

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.

jpalawaga 1y ago
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.
petersellers 1y ago
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).

Traubenfuchs 1y ago

What are unit tests?

deleted 1y ago

[deleted]

mediumsmart 1y ago

I remember using JavaScript when building websites.

tobyhinloopen 1y ago

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/ 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/Reference/Global_Objects/Temporal 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 https://www.npmjs.com/package/temporal-polyfill For experiments, I would strongly suggest to look into Temporal API.