4 ms·
> That'd test all the software paths. The daylight savings time bugs I've run into at pretty much every company I've ever worked at would beg to differ.
by cactus2093 4y ago
> That'd test all the software paths.
The daylight savings time bugs I've run into at pretty much every company I've ever worked at would beg to differ.
- throw0101a 4y agoSee also leap year bugs even though that concept has been around even longer than DST.
- FeistySkink 4y agoMy favorite is comparing aggregated data across several time zones when DST changes happen.
- bentcorner 4y agoShouldn't you just aggregate based on UTC? Leap seconds still cause a problem here but daylight savings shouldn't matter.
- FeistySkink 4y agoHow does that solve comparing days with 23 to 25 hours of data when aggregated by hour? Or are you suggesting using days in UTC?
- andreareina 4y agoThe problem is that if the originating system didn't record the time in utc, you've lost the information needed to make the time unambiguous. What's 2022-11-06 01:30 USA/San Francisco in UTC?
- Matumio 4y agoPeople expect e.g. their "daily power consumption" to end at midnight local time. When they zoom in on the daily aggregates, they don't want a spike to suddenly disappear just because it belonged to the next local day and you only stored UTC-day aggregates. Even more so for billing.