2 ms·
We're already in a world where you really need to rely on external date+time libraries to apply a locale-specific temporally-varying offset from UTC. I don't s
by newnewpdro 8y ago
We're already in a world where you really need to rely on external date+time libraries to apply a locale-specific temporally-varying offset from UTC.
I don't see it as being a significant implementation difference if that offset changes a smaller amount at midnight on a short sequence of days vs. a larger amount at midnight on just one of those days.
Either way you need to be leap-aware.
- recursive 8y agoThe amount of information embedded in leap-awareness would be significantly different. Right now DST is modelled as two different time zones that are switched between. If you want to handle it the same way, I guess you'd need 365 (366?) "time zones" per time zone. I can't see how you can argue that's not a significant implementation difference.
- newnewpdro 8y agoLet's say we wanted to turn it into a gradient where we instead shifted five minutes per night, so we need 12 days to transition an hour. You could just add a transition countdown field "-" to the "S" and "D" timezones being transitioned to, dropping it once the transition is finished. e.g. for Pacific time: PST -> PD-12T -> PD-11T -> PD-10T ... PD-1T -> PDT and in reverse: PDT -> PS-12T -> PS-11T -> PS-10T ... PS-1T -> PST If you already have the indirection of the table, it doesn't increase implementation complexity to put some more rows in it. I don't see where you got 365 zones per time zone, unless you thought I was proposing we change the time a little bit every single day of the year. That's entirely unnecessary to eliminate the practical nuisance of the sudden 1-hour jump.