[cactus2093]

> 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]

See also leap year bugs even though that concept has been around even longer than DST.

[FeistySkink]

My favorite is comparing aggregated data across several time zones when DST changes happen.

[bentcorner]

Shouldn't you just aggregate based on UTC? Leap seconds still cause a problem here but daylight savings shouldn't matter.

[Matumio]

People 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.

[andreareina]

The 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?

[FeistySkink]

How does that solve comparing days with 23 to 25 hours of data when aggregated by hour? Or are you suggesting using days in UTC?