Live data from Hacker News

JavaScript decided my day starts at 9am

senhongo.com

41–47 of 47 posts

Re: JavaScript decided my day starts at 9am

#41
post #10

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…

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.

Re: JavaScript decided my day starts at 9am

#42
post #31

Earlier quoted context omitted.

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…

> 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 f…

So it does not take the year into consideration? Well damn.

Re: JavaScript decided my day starts at 9am

#43

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/...

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.

Re: JavaScript decided my day starts at 9am

#44
post #31

Earlier quoted context omitted.

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…

> 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 f…

I am sure the "as a user, I should see relative timestamps" ticket was closed fast though! Another job well done!

Re: JavaScript decided my day starts at 9am

#45

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/...

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:…

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.

Re: JavaScript decided my day starts at 9am

#46
post #27

Earlier quoted context omitted.

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-…

Using a VPN doesn't change your time zone

Re: JavaScript decided my day starts at 9am

#47
post #11
post #4

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.

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.
Post reply on HN