6 ms·
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 befo
by s3m4j 8y ago
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.
- taeric 8y agoThis works for things that have happened. It doesn't work too well for schedules. In those cases, the timezone of the source matters, heavily.
- majewsky 8y agoFor 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.
- falcolas 8y agoOr, 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.
- s3m4j 8y agoTo this day, knock on wood, I have had success at voluntarily avoiding those issues ^^ (aside from school assignements)
- marcosdumay 8y agoThere 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.
- everybodyknows 8y agoYes, 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.