Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JavaScript decided my day starts at 9am

senhongo.com

Post reply on HN
Print view View original

21–30 of 47 posts

Re: JavaScript decided my day starts at 9am

#21

Post by afiori »

blahedo wrote: post #14
sgentle wrote: 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…

The issue here is that timezone are often handled like an environment setting instead of as an element of the day-time-timezone tuple

Re: JavaScript decided my day starts at 9am

#22

Post by CuriousRose »

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.

Re: JavaScript decided my day starts at 9am

#23

Post by AdieuToLogic »

austin-cheney wrote: post #18
AdieuToLogic wrote: post #16

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…

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.

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

Re: JavaScript decided my day starts at 9am

#24

Post by dgfitz »

whatevaa wrote: post #20
koito17 wrote: 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…

Nothing wrong with this. Operating in one timezone only simplifies things, no need to overcomplicate it.

Following this logic, python 3 needn’t have been created.

Re: JavaScript decided my day starts at 9am

#25

Post by bigDinosaur »

whatevaa wrote: post #20
koito17 wrote: 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…

Nothing wrong with this. Operating in one timezone only simplifies things, no need to overcomplicate it.

Obvious potential failure case: Japanese citizens who are travelling abroad.

Re: JavaScript decided my day starts at 9am

#26

Post by jpalawaga »

CuriousRose wrote: post #22

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…

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.

Re: JavaScript decided my day starts at 9am

#27

Post by koito17 »

bigDinosaur wrote: post #25
whatevaa wrote: post #20

Earlier quoted context omitted.

Nothing wrong with this. Operating in one timezone only simplifies things, no need to overcomplicate it.

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

Re: JavaScript decided my day starts at 9am

#28

Post by petersellers »

CuriousRose wrote: post #22

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…

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