Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Time is two different things. Just making everything UTC until display time is incompatible with that. Sometimes you need to operate on calendar units or clock units as part of business logic.


> Sometimes you need to operate on calendar units or clock units as part of business logic.

And you must do it in UTC


To make something happen at 9 AM every day in the user’s time zone, choosing UTC will make it harder.


Needs must.

But otherwise use UTC

A local time aware process has to be available for users. Of course

But in the backend it is UTC

Storing time any other way is a world of pain


> But in the backend it is UTC

Scenario 1: You have an event to schedule at 9am local at some future date. You want to convert to UTC. But you can only do that if you know the offset, and the offset for future dates can change or be unknown. How do you resolve this?

Scenario 2: Now the event is "9am every day, indefinitely". How do you represent that as UTC? Do you generate tens of thousands of separate timestamps?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: