Comment by sgentle | Hacker News Reader

Comment by sgentle | Hacker News Reader

Parent Full thread

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.

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.

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

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.

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.

Reply on news.ycombinator.com