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