Your biyearly DST pain continues... check your scheduled events!

[James Sentman]

At least now the DST flag change is correct I can test the remaining possibilities by just reseting the clock, so we can sort it out now. With carbon apps the DST flag was changed but the time also changed and then the dst flag was applied to the time, that had already been changed, effectively changing it back… All that happened in the framework stuff and after the change there was no way to sort that out, all dates were completely messed up in an app that lived through the DST change. That is no longer the case now that we’re a cocoa app.

So the rest we can finally sort out now! As much as I am hating myself at hanging up peoples event queues last night, at least now it’s going to be actually possible to sort out the rest of the logic for handling it.

I am going to do some serious brainstorming and will chime into the list to get you guys to think about the details of it periodically as I decide how best to handle it.


> On Mar 13, 2016, at 11:36 AM, WILLIAM J HUSLER <bhusler at me.com> wrote:
> 
> I can certainly see the dilemma with the fall time change (I do wonder why we do the whole Daylight savings time thing any more anyway). I can think of scenarios where an event that ends up scheduled for 1:30am should run only on the first instance, only on the second instance or on both instances (first, last, every). Seems to me that which ever approach you take, if you only pick one it can’t cover all the options. I think maybe a system wide default for the behavior and a new optional parameter for the create event and for/until clause would cover it though.
> 

Thanks,
 James


James Sentman                       http://www.PlanetaryGear.org		http://MacHomeAutomation.com




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.machomeautomation.com/pipermail/xtensionlist/attachments/20160313/9c42723e/attachment.html>