For the record, my RD’s behavior this year seemed to match Rob’s; at 3AM local, the 0200 AM programmed hour fired and played (since I had no other hard breaks during that hour). This year, for whatever reason, I removed some of the hard breaks around the 0200 standard time hour, not sure I did that last year, don’t recall having an “issue” last year. At that time of night, I usually have TOH hard breaks at 00:00.
Like Rob, not a major or minor complaint… as long as there’s not dead air, I’m happy with whatever runs (!!!). in His service, BJ Mora for GraceRadio at graceradio.net KGCE-LP/Modesto NOW at FM 107.9! > On Mar 11, 2019, at 5:19 AM, [email protected] > wrote: <snip> > Message: 3 > Date: Sun, 10 Mar 2019 15:42:15 -0400 > From: Fred Gleason <[email protected]> > To: User discussion about the Rivendell Radio Automation System > <[email protected]> > Subject: Re: [RDD] Daylight Saving Time issue > Message-ID: <[email protected]> > Content-Type: text/plain; charset="utf-8" > > On Mar 10, 2019, at 14:14, al davis <[email protected]> wrote: >> >> Not a surprise ... For that instant, the time is 2 AM, but one second >> later it's 3:00:01. The exact time of 3 AM does not exist. It's just >> like 2:30 AM. > > Not quite. In the United States, the forward transition looks like this: > > [?] > 01:59:58 > 01:59:59 > 03:00:00 > 03:00:01 > [?] > > So 03:00:00 actually does exist. The entire 2 AM hour however is skipped. > > (Please note that this applies to forward transitions in the *United States*; > other jurisdictions apply DST on different dates and at different times, > where they apply it at all) (not all US jurisdictions apply it either). > > >> What would you expect it to do with an event scheduled at 2:30 AM, in >> the middle of the hour being skipped? I am not asking what it does. I >> am asking what it should do. > > That?s an easy one: skip it! 02:30:00 doesn?t exist in that case. > > >> What should it do for an event scheduled at exactly 2 AM? > > Ditto. > > The really ?interesting? cases are those that arise in the Autumn (?fall > back?) transition, where the clock does this: > > [?] > 01:58:59 > 01:59:59 > 01:00:00 > 01:00:01 > [?] > > So here, you get *two* 1 AM hours, occurring back-to-back. So, what ought to > happen to an event that is scheduled to execute at (say) 01:15:00? Should it > run just the first time? The second? *Both*? > > But to answer Rob?s original question: the behavior of RDCatch at a DST > transition is currently ?undefined? (which is a weaselly way of saying ?we > have no idea what it does?). > > Cheers! > > > |---------------------------------------------------------------------| > | Frederick F. Gleason, Jr. | Chief Developer | > | | Paravel Systems | > |---------------------------------------------------------------------| > | A room without books is like a body without a soul. | > | | > | -- Cicero | > |---------------------------------------------------------------------| > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <http://caspian.paravelsystems.com/pipermail/rivendell-dev/attachments/20190310/68174569/attachment-0001.html> > > ------------------------------ > > Message: 4 > Date: Sun, 10 Mar 2019 20:57:51 -0400 > From: Chuck <[email protected]> > To: [email protected] > Subject: Re: [RDD] Daylight Saving Time issue > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="UTF-8" > > Adding to Lorne's comment, I have always avoided using the exact TOH as > an event time on time-change night and have never had any trouble in 5 > years of running Rivendell. Also, just adding a report that an event > for 03:00:13 last night, executed perfectly. > > But if you are meeting the network straight up, that might pose a > problem. Perhaps a possible couple second upcut twice a year in the > dead of night is acceptable? > > --Chuck W. > > On Sun Mar 10 13:22:03 EDT 2019 > Lorne Tyndale ltyndale at tyndaleweb.com wrote: > >> If the clock is correct and changes as it should then this should >> work. > >> However if for some reason the clock doesn't change, or if you're in >> a networked environment where all the rivendell workstation clocks >> are not sync'ed with the server, then I've run into issues - not >> related to time change, but related to when a workstation triggers >> an event versus the time the server has (particularly with rdcatch). >> >> One option is to schedule the event for 1 to 2 seconds after the TOH, >> I've found that smooths out the RDCatch issues that I see >> occasionally. I imagine it should work for time change too. >> >> Lorne Tyndale > > On Sun, 10 Mar 2019 07:39:22 -0400 (EDT) > Rob Landry <[email protected]> wrote: > >>> One of my clients had a timed event scheduled for 3:00 AM this >>> morning, that is, for the instant that 2 AM suddenly becomes 3 AM, >>> and the event did not fire. >>> >>> Does anyone know if this feature has ever been tested under these >>> conditions? >>> >>> >>> Rob > > > > > ------------------------------ > > Message: 5 > Date: Mon, 11 Mar 2019 08:19:57 -0400 (EDT) > From: Rob Landry <[email protected]> > To: al davis <[email protected]> > Cc: [email protected] > Subject: Re: [RDD] Daylight Saving Time issue > Message-ID: <[email protected]> > Content-Type: text/plain; charset="koi8-r"; Format="flowed" > > On Sun, 10 Mar 2019, al davis wrote: > >> What would you expect it to do with an event scheduled at 2:30 AM, in >> the middle of the hour being skipped? I am not asking what it does. I >> am asking what it should do. > > I am not complaining, mind you, merely passing along the concerns of a > client, for the benefit of those who might want real-world feedback. > > The fact that someone whould choose to schedule a timed event at 3 AM on a > "spring ahead" day is nothing short of astonishing to me, but then people > keep scheduling them at 11:59 PM and then wondering why the next day's log > got skipped. They ought to know better. > > > Rob > > -- > ? ???, ??? ?????? ????????, > ? ???, ??? ??????? "??????", > ??? ????? ??????? ????? > ?????? ???????? ????. > > ------------------------------ > > _______________________________________________ > Rivendell-dev mailing list > [email protected] > http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev > > > End of Rivendell-dev Digest, Vol 71, Issue 11 > *********************************************
_______________________________________________ Rivendell-dev mailing list [email protected] http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
