Oof. I would say to use the Advanced Scheduler module on the backend and just create the schedule in DGLux (well, you'll have to do something like that, since DGLux isn't running when it isn't open). I would have such a strong preference to that I would contemplate convoluted workaround like having a second Mango on the later versions and embed the advanced scheduler into a portlet in DGLux, then use some kind of publisher to alert the 2.x instance when the event is active. You could have both running on the same machine.
Implementing a scheduler has some considerations to keep in mind. Time alleges to do different things in different parts of the world, and some human readable times never occurred despite appearing to be a valid time, and occurring between times that did occur. The more feature-rich your scheduler is going to be (or serve a larger audience), the more you have to think about that kind of thing.
If however you're deploying only one and it's not entering a code every 13.23 minutes to prevent something from exploding and it's a little more forgiving, you could encode some kind of schedule information into a script (like stringifying JSON into an alphanumeric point, then using
JSON.parse in the scripting ds) and have it execute every minute or so to assess state transitions. You have to solve sudden power loss problems somehow along the way, probably tracking the state of the schedule. If it's even simpler as to say 'point x needs value y at time z,' then you could consider simplifying things for yourself with an inefficiency like setting the value it should have to the point every poll of the scripting data source that digests this encoded schedule.