Hacker News Reader

Comment by s3m4j | Hacker News Reader

In my experience, it's been easier to push UTC time all the way from the db to the user javascript and operate on time then, than trying to manipulate time before sending to the user. YMMV, and it's only web dev.

View on HN

There are many kinds of data that get saved as time. For some, yes, it's better to add and remove the TZ at the interface. For some the TZ carries meaning by itself, and it must be stored and keep constant everywhere. For some the TZ carries meaning, but the time must be converted for display.

Know your data, and most of your problems get easy.

Yes, that's the crucial distinction -- whether the TZ, with its coarse encoding of the geography of origin, carries significance to the consumer of the data.

This works for things that have happened. It doesn't work too well for schedules. In those cases, the timezone of the source matters, heavily.

For example, a task that occurs "daily at 15:00" does not always happen every 24 hours. When DST comes into effect, the interval shortens to 23 hours once.

Or, at "2:30 am" in the continental US can occur twice in a day, or not at all. Of course, even that isn't guaranteed, if you're in AZ.

Even "notify me in exactly 24 hours has its own complications. Leap seconds will screw up your day (as will the vague request of "exactly 24 hours").

Corner cases, the bane of simplicity everywhere.

To this day, knock on wood, I have had success at voluntarily avoiding those issues ^^ (aside from school assignements)

Reply on news.ycombinator.com