perishthethought@lemm.ee to Programmer Humor@lemmy.mlEnglish · 11 months agoI think my code will be OK...i.imgflip.comimagemessage-square52fedilinkarrow-up1339arrow-down17file-text
arrow-up1332arrow-down1imageI think my code will be OK...i.imgflip.comperishthethought@lemm.ee to Programmer Humor@lemmy.mlEnglish · 11 months agomessage-square52fedilinkfile-text
minus-squareprojectmoon@lemm.eelinkfedilinkarrow-up8·11 months agoBut wouldn’t you calculate the time in the future in the right time zone and then store it back as UTC?
minus-square48954246@lemmy.worldlinkfedilinkEnglisharrow-up1·11 months agoIt depends on the application. I don’t remember all the specifics but this is the blog post I refer to when this topic comes up https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a-silver-bullet/
minus-squaremagic_lobster_party@kbin.sociallinkfedilinkarrow-up5·11 months agoSo TL;DR: there might be unexpected time zone rule changes in the future. The solution presented in the article is to store both UTC and local time, so the application can easily adjust itself if such change happens.
But wouldn’t you calculate the time in the future in the right time zone and then store it back as UTC?
It depends on the application.
I don’t remember all the specifics but this is the blog post I refer to when this topic comes up
https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a-silver-bullet/
So TL;DR: there might be unexpected time zone rule changes in the future. The solution presented in the article is to store both UTC and local time, so the application can easily adjust itself if such change happens.