[msm23]

I believe the use case is for scheduling systems that need to do something at (say) 1:30am. On every day at 1:30am, please run the accounting job.

In the US, once a year you either have to have some locking system set up to avoid the second run (leave a trace that the job has already been started for the day). I believe the person proposing this thinks that it would make this determination easier.

The problem is that it only solves half the trouble caused by dual timezones. There's another day of the year when 2:30am (in the US) doesn't happen at all. If something is scheduled to occur once per day at 2:30am, then that day it is not going to happen.

There are other workarounds available such as avoiding the magic hours around 2am (in the US). But it seems to be a common problem that everyone seems to keep re-solving.

Storing the timezone with the time doesn't really solve the above issue.

[kbenson]

> I believe the use case is for scheduling systems that need to do something at (say) 1:30am. On every day at 1:30am, please run the accounting job.

In the instance where someone wants something to happen at 1:30 AM, if they aren't specific in the specification, then they should expect that it may happen twice or not at all at at certain times of the year. This is an imprecise specification problem, not a problem in representing time in structures that can and do contain timezones. That is, it's a failure of cron, or the user specifying the time, take your pick. What it's not is a failure of dates, times and timezones, which specifically address this problem. Timezones or UTC (which is just timezone offset 0), are what we have to deal with this specific problem.

For example, specifying the originating timezone would disambiguate the time, as would specifying it in UTC, (or automatically converting to and using the UTC equivalent on entry).

> Storing the timezone with the time doesn't really solve the above issue.

It doesn't address the "do this thing at this local time daily" problem when someone chooses a time that has special behavior, but it does address the "do this thing at this offset from UTC daily" which may be the best you can expect when specifying a time for a recurring action and not taking into account timezones. If you want to use local time, you have to deal with either the actually time the job runs possibly shifting slightly throughout the year in some locations, or possibly running twice or not at all.

My real problem with the proposal is that adding a .first() method doesn't solve anything, and really just makes half the problem (it doesn't work if the time doesn't exist), and in a way that's already easily solved, since you can't get a valid result from .first without knowing the timezone already.

[marcosdumay]

Storing it as an offset from UTC has the effect that the task will run at the wrong time 1/4 of the year.

Now, you'll probably claim that I shouldn't expect time to behave this way. But this is exactly the way everybody expect time to behave, thus, no I won't agree with you.

Anyway, yes, that still does not solve the entire problem. Time intervals are really messy.

[kbenson]

> Now, you'll probably claim that I shouldn't expect time to behave this way. But this is exactly the way everybody expect time to behave, thus, no I won't agree with you.

You shouldn't expect time to behave that way. Cron-like programs also should try to do the right thing. What's really missing is an up-front understanding of what users are to expect when entering a time into a program that supports recurring time. This is a failure of most programs to account for common misconceptions.

This proposal doesn't really help this, as it only detects the instances where we duplicate time, and only where you already have a time zone applied.