Reports if a DST change is pending between two times:

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) {
		$g{log}->debug ( "DST change is pending! $nStartDate isDST: $isdst1 vs. $nEndDate isDST: $isdst2\n");
		if ($isdst2) {
			return 1;	#Spring ahead..assumes that $nEndDate > $nStartDate
		} else {
			return -1;	#Fall back...
		}
	}
	return 0;                       #No change pending..
}

Slim::Utils::getNextAlarm() returns an alarm object, not the time of the next alarm.  Could you provide a bit more detail about what you're trying to do?

Yes...I see your point.  Perhaps my problem is really with findNextTime()

I'm trying to get the epoch date/time of the next alarm that SC will try to service.  Here is how I'm doing it:

my $nNextAlarmTime = 0;
my $szNextAlarmClient = "";

foreach my $curClient (Slim::Player::Client::clients()) {
	$curAlarm = Slim::Utils::Alarm->getNextAlarm($curClient, 1);
	if (defined($curAlarm)) {
		$nAlarmTime = $curAlarm->findNextTime(time());
		$szAlarmClient = $curClient->name();
			
		if ( (!$nNextAlarmTime) || ($nAlarmTime < $nNextAlarmTime) ) {
			$nNextAlarmTime = $nAlarmTime;
			$szNextAlarmClient = $szAlarmClient;
		}
	}
}

return $nNextAlarmTime;

Shouldn't findNextTime() return the same epoch date/time for the alarm regardless of whether or not there is an intervening DST change?

I.E. if the system time is sixty seconds before a DST change, findNextTime(time()) returns one answer and  findNextTime(time()+61) returns a different answer.  To me, the former is the "wrong" answer.  Epoch time is epoch time and shouldn't change in this case, imho.

Max, whats your though on the comment #3

I think Gordon has a point, but I don't think it's a problem that would affect the core alarm functionality.  We should probably fix this, but I wouldn't say it was a priority.  Off the top of my head, findNextTime probably needs to be using gmtime where it uses localtime, but it needs some careful thought.  Patches welcome!

For what it's worth, I agree that this is of minor..or even trivial importance.  Max is, as far as I can tell, right in that there is currently no impact from this on the functionality of any SD hardware.  As long as the SqueezeCenter server keeps awake and running through the DST transition, alarms are serviced at the appropriate time.

With the SB Boom, if the server is down during a DST transition, the Boom's backup RTC alarm behaves like any dumb alarm clock...i.e. the backup alarm will sound an hour 'off'.

I raised this simply because I'm calling findNextTime() from the SrvrPowerCtrl plugin in order to schedule the server's RTC alarm to wake the server at the appropriate time.  Currently, my code has to compensate on DST transition days for the fact that findNextTime() returns the incorrect epoch date/time for the next alarm IF the DTS transition occurs between the call to findNextTime() and the actual alarm.

So..I raised this more in the spirit of an 'FYI' than something that presents a need with the currently released hardware.

Andy says, 'Patches welcome'

Understood.  I'll start working on one.

I didn't mean to be brusque or demanding; we were just in a bug meeting and trying to get through a lot of bugs that needed review!

Thanks for anything you can contribute, or, if you find you can't finish the project, I hope your work so far can help another contributor, or an in-house developer at some point in the future.