4 ms·
Yeah, and even if those assumptions are perfectly fine today, they are unlikely stay that way. When they do, going back and fixing everything else is a massive
by outworlder 2y ago
Yeah, and even if those assumptions are perfectly fine today, they are unlikely stay that way. When they do, going back and fixing everything else is a massive pain. Even ensuring everything is in localtime can be a pain; someone decides to add a database you didn't have before and didn't pay enough attention to its configuration? Too many landmines.
The way to avoid this pain is to just use UTC on day one, regardless of requirements. Hard and fast rule that everything needs to be UTC. Need to display it? Converting to local time is trivial.
Same thing for text. Use Unicode unless otherwise specified.
- dspillett 2y ago> just use UTC on day one, regardless of requirements That can cause extra concerns for always-in-one-timezone systems where you might care where midnight falls (“did this event happen today or yesterday?” is a question that needs extra steps to answer, for instance). Nothing complicated, but extra work you might want to skip at the quick PoC stage. But yes, beyond PoC work and all but the simplest other work, I'd agree with UTC all the way from the ground up.