perishthethought@lemm.ee to Programmer Humor@lemmy.mlEnglish · 1 year agoI think my code will be OK...i.imgflip.comimagemessage-square53fedilinkarrow-up1341arrow-down17file-text
arrow-up1334arrow-down1imageI think my code will be OK...i.imgflip.comperishthethought@lemm.ee to Programmer Humor@lemmy.mlEnglish · 1 year agomessage-square53fedilinkfile-text
minus-squareprojectmoon@lemm.eelinkfedilinkarrow-up8·1 year 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·1 year 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·1 year 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.