epoch1970;374981 Wrote:
> Hum. I Don't know of a mnemonic. We call the summer and winter periods
> "heures d'été" (summer) and "heures d'hiver" (winter); So I guess it's
> clear enough the direction in which the clock goes. We're very clever,
> you know ;)
I know you are. In fact, out of deference to French cleverness in
general, whenever I say the word "clever", I always pronounce it with
my best Jacques Clouseau accent: "clev-airgggggh." ;o)
epoch1970;374981 Wrote:
> I wrote a long response, then scratched it off to say this: unless
> getNextAlarm guarantees to respond an epoch date (ie an absolute UTC
> date) that is:
> 1) picked among all known players *at the time of the query*,
> regardless of their current status (incl. on SC/on SN)
> 2) valid for the selected player be it on SC or SN at the time *of the
> alarm*
> then I think we're in the mud. (endless clash of policies, complex
> code, heavy maintenance, unhappy users)
>
> For me, a clear indication is if the routine also reports on players
> connected to SN at the time of the query.
> If it doesn't, then I feel the contract is too weak. SN does/will muck
> with alarms and SC being asleep couldn't do anything to avoid failure.
> If it does, there's a good chance you shouldn't have to care at all
> about DST changes.
I agree: I think that I won't really know where I stand until I can do
some serious testing. If getNextAlarm does indeed always respond with
an epoch date, then that's half the battle.
epoch1970;374981 Wrote:
> (In any case, DateTime I used in my code has an isDST method you can
> call on a date object (which has a TZ). If you call it on the query and
> alarm dates and see it flipping 0/1 or 1/0, you can start the
> incantation of your liking... )
This is the code I wrote yesterday...but I haven't run or tested it
yet:
Code:
--------------------
sub IsDSTChangePending {
my ($nStartDate, $nEndDate) = @_;
my ($sec1,$min1,$hour1,$mday1,$mon1,$year1,$wday1,$yday1,$isdst1) =
localtime($nStartDate);
my ($sec2,$min2,$hour2,$mday2,$mon2,$year2,$wday2,$yday2,$isdst2) =
localtime($nEndDate);
if ($isdst1 != $isdst2) {
if ($isdst2) {
return 1;
} else {
return -1;
}
}
return 0;
}
--------------------
So, if IsDSTChangePending(time(), $nNextAlarmTime) returns 1 (Spring
ahead), I'll ask the rtc to wake up an hour earlier. If it returns -1
(Fall back) I could postpone the rtc wakeup for an additional hour.
Please tell me that the French, that great nation of rationalists,
don't do anything as bizzare as is common in the States: allowing
small, local units of government to opt out of observing DST. There is
no DST for the entire state of Arizona. You used to find individual
counties in states like Indiana that didn't observe DST. Thus the map
of the "edge" of a time-zone in the US ends up looking "furry" and
changes from season to season. But in France, it's all just one
time-zone, right?
I ask this because my dream of the ultimate beta test of SrvrPowerCtrl
would involve a SqueezeBox, a small 12v powered SqueezeCenter server
with my music collection, a barge and the Canal du Midi. I'd hate to
think that I would have to reset the locale on the server every couple
of kilometers.
--
gharris999
------------------------------------------------------------------------
gharris999's Profile: http://forums.slimdevices.com/member.php?userid=115
View this thread: http://forums.slimdevices.com/showthread.php?t=48521
_______________________________________________
plugins mailing list
[email protected]
http://lists.slimdevices.com/lists/listinfo/plugins
