I was working on a unit test one day for a calendar feature in my android app. I wanted to make sure that it worked for daylight savings time.
Realizing that, in the spring, the calendar jumps from 2 AM to 3 AM, and this is not a problem for testing. You simply pick the date and 2 AM or 3 AM. Anything in the interim is an invalid time. Easy.
The problem is with the end of daylight savings. Coming up, on Sunday, November 3, will be two 1 AMs. The first one, and then the second one 1 hour later. In fact, this problem applies to all of the times between 1AM and 2AM on Sunday.
How do you specify a time in normal format that differentiates between them? The answer, you can’t. There’s two 1 AMs here and there’s simply no way to tell the difference without using UTC.
I ended up taking 12:59 AM and converting it to UTC milliseconds since midnight, January 1, 1970, then adding one minute to that serial number to advance to the first 1AM. Then adding 59 minutes to this number takes you to 1:59 AM. Adding one more minute then takes you to the second 1AM, then proceeding normally after that.
And that’s how you handle daylight savings time. Things you don’t think about when you’re not a software engineer…