Live data from Hacker News

JavaScript decided my day starts at 9am

senhongo.com

31–40 of 47 posts

Re: JavaScript decided my day starts at 9am

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

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 from "one year ago" to "one hour ago" because the two comments happened to be something like Dec 31 and Jan 2.

Re: JavaScript decided my day starts at 9am

#32
post #6
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

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

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.

Re: JavaScript decided my day starts at 9am

#33

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.

Or 9 days, depending on the time zone you're in

Re: JavaScript decided my day starts at 9am

#34
post #9

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

Re: JavaScript decided my day starts at 9am

#36
post #9

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…

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.

Re: JavaScript decided my day starts at 9am

#37
post #34
post #9

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

[deleted]

Re: JavaScript decided my day starts at 9am

#38
post #14
post #9

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…

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.

Re: JavaScript decided my day starts at 9am

#39

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…

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.

Re: JavaScript decided my day starts at 9am

#40
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.

Post reply on HN