2 ms·
> some days have 25 hours I'm curious to know in what circumstance you think a UTC day has 25 hours. > it has tricky consequences for UI layout and printing i
by deathanatos 13y ago
> some days have 25 hours
I'm curious to know in what circumstance you think a UTC day has 25 hours.
> it has tricky consequences for UI layout and printing if those night hours matter.
This is very true. I don't believe Google Calendar (or any calendar app that I've seen, really) handles displaying DST weirdness well. It would be very tricky to render. I'd love to see something attempt to tackle this.
- PeterisP 13y agoYou can (and likely should) choose to store your locale-specific times in UTC, but you often can't choose to define 'days' as UTC days. If your days are meaningful for your app in any way, then you have to have clear boundaries between days/weeks/months - if your website has a report 'downloads per day', then it doesn't mean UTC days (which for many locations would mean splitting in the middle of business hours. And it has days where the difference between 'start-of-day' and 'end-of-day' is not 24 hours, but 25 hours. Also, no matter how you handle time storage, if you're doing any analytics, and your process is minute-dependent instead of day-dependent (say, power consumption, not purchases), then your daily totals will have ~5% jumps twice a year that you might need to adjust.