Hacker News Reader

Comment by koolba | Hacker News Reader

Sounds like a time zone round trip issue. They’re likely using timestamps (say epoch millis) to represent dates and converting it incorrectly on display.

View on HN

This mistake is quite easy to make in JavaScript. Dates are internally milliseconds since epoch but if you construct a date by giving year, month, day, you get midnight in the local timezone which may well be on a different day from midnight in UTC, so if you send back a unix timestamp or (trying to be clever) use UTC functions to get a date from a Date object, you may likely get an off by one error.

Another consequence of this is that JS Date objects don't understand the concept of timezones, and only allows you to output dates in either the client timezone or UTC. This makes it extremely hard to, for example, display the arrival time of a flight in the destination timezone.

Intl.DateTimeFormat[1] is a godsend for this.

[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Sounds like a fundamental misunderstanding about the difference between a birthdate and an instant on a timeline.

Not a misunderstanding, I'm sure they understand birth dates. But that the date picker selects the current time by default, and doesn't make that visible to the user.

Birthdates are complicated. It's quite possible for you to tell someone your birthday and be "wrong" because of the timezone you are in. Or for you to be more or less "years" old than your birth date indicates because of timezone differences between where you were born and where you are now. Rarely matters. Simple mistake in code to forget that a birthdate should be treated as having no timezone.

Depending on time of birth it could have been you that was off by one

There should be no time component to a properly-stored birthdate. One doesn't observe a "January 1 in Australia" birthday on December 31 in New York. Systems that presume a birthday to be other than a year+month+dayofmonth get themselves into the sort of trouble described in this thread. Birthdays well in the past, however, might need more information on the observed calendar/chronology in use in the subject's locale.

OTOH, if you need "instant of birth" then definitely get a time and timezone. Plus, converting to UTC and discarding the timezone observed at the place and political circumstance of birth would likely be a mistake.

My point is that no one "misunderstands" this. Everyone knows a birthday encompasses an entire day. This is a bug, not a misunderstanding.

I feel you're being pedantic. The misunderstanding is not around the concept of a birthday, yes--it's due to the use of a time-having datetime datatype for this purpose, in UI and/or application server or database layers, the latter of which ought to reject datetimes as nonconforming inputs.

Might be even worse, a lot of systems only have some sort of DateTime object that automagically includes a time component (no real way to specify date-only except just using a plain string) and automagically tries to correct it based on some sort of cascade of system settings, configuration variables, application configuration, and user configuration. On a web app, those things probably exist at least on the client, server, and database, each potentially making their own attempt to 'fix' the data.

Working with dates in code is unnecessarily hard so naturally the results tend to be bug-ridden more often than not.

Reply on news.ycombinator.com