[msm23]

Yes, you could get the information from the timezone, but how would one do that in code?

The only time that one has the time fold is when you turn the clock backward (let's just call that shifting from daylight savings to standard timezone). And this would only affect code which used wall clock time (time as it's read, e.g. 1:30am PDT), and would also only affect code which wanted to run something only once at a time within that fold (e.g. 1:30am ... not on both 1:30am's).

So, using the timezone method, just check to see if your current 1:30am is in your daylight savings timezone. Hurray! You're in the clear. Go ahead and do that thing you wanted to do only on the first 1:30am.

But the next day you're going to run into a problem. The only 1:30am you're going to get is in the standard timezone. So now you have to check for this timezone change only on the day of the change, which is yet another piece of data you have to keep track of. On the day of the change, do this timezone comparison, and on every other day don't worry about it.

When the clock hits your interesting time of 1:30am, just check to see if today is the day of the change, check what the current timezone is, check what the daylight savings time zone is, check to see if those those two values are the same, and now do your thing. Otherwise, just do your thing.

All of the above also ignores that people change times at different times (11pm, 1am, 2am, 3am), some don't change a full hour, and some don't change at all.

The proposal gets rid of all of that convoluted logic in everyone's programs, and instead it provides a single boolean value: is this the second time I've seen this time because of daylight savings shenanigans.

[IanCal]

> The proposal gets rid of all of that convoluted logic in everyone's programs

Does it? It doesn't cover the scheduling problem the other half of the year when the clocks move the other direction.

> So now you have to check for this timezone change only on the day of the change, which is yet another piece of data you have to keep track of.

If running a job twice is a problem, then why not check that the job has not already been run?

> is this the second time I've seen this time

Is this unambiguous? If it's 2015-10-25-01-30-00 GMT, have I seen that time before? In the UK, yes, in Mali no.

[ars]

You don't need to do any of that. Just get a unixtime, and move on.

Why are you doing time math in local time?

Simply do all the time math in universal time and be done with it.