[mrweasel]

Sort of side note, but some IT systems do in fact need to deal with 25 hour days, due to daylight savings time. If your system deals with schedueling electricity production, you may need to accept that one day a year may only have 23 hours while another have 25.

[mjevans]

It's usually easy to relegate yourself to the issue of various periodic measures being some crazy human duration long and just writing the software to use a common date/time library and live with it.

Harder are the moments when you actually care if one time has longer seconds than another due to leap seconds or smearing over the day to spread out a leap second.

It's really just easiest if you take nothing for granted, and even assume that clock-cycles aren't of a fixed duration but of a given quanta of work.

[SAI_Peregrinus]

> It's really just easiest if you take nothing for granted, and even assume that clock-cycles aren't of a fixed duration but of a given quanta of work.

Thanks to spread-spectrum clocking, this really ought to be the default assumption for most computers. It's a small variance, but it's there.

[jedberg]

I always solved this by setting my systems to a time zone without DST. Since I am in California, I always use Arizona time. 9 months of the year it's the same as mine and the other 3 I can easily subtract 1.