3 ms·
Let this be a lesson to developers of MVPs. No matter what, use Unix timestamps for times and then account for time accordingly using libraries that have done
by blantonl 6y ago
Let this be a lesson to developers of MVPs.
No matter what, use Unix timestamps for times and then account for time accordingly using libraries that have done this heavy lifting for you.
It's easy to just use local timestamps out of the gate, or any other shortcut that doesn't account for the fact that timezones across the world are weird and changing, and the whole daylight savings thing.
The amount of technical debt you can get into when your app gets popular around the world can be soul crushing, and it's certainly not an good user experience when local time isn't available to them in your app.
- iso1210 6y agoIf you are writing a calandar app that has an event that occurs every morning at 0900 in New York, you need to store that at 0900 America/New_York, not at 1400 GMT, or the unix time of 1400 GMT and adding 86,400 seconds.
- svieira 6y agoIf you're writing a calendar app, then you should probably store the triple of `local time`, `time zone name`, `version of time zone database used to look up time zone name` https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a-silver-bullet/ https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a... and http://www.creativedeletion.com/2015/03/19/persisting_future_datetimes.html http://www.creativedeletion.com/2015/03/19/persisting_future...
- spookthesunset 6y agoSeriously folks. Don’t start out using local time. Start with UTC. Always. If you don’t do dates and times properly in the first place your system will always do them somehow wrong.