rickwookie;415592 Wrote: > I can't help thinking that this seems over engineered. Wouldn't it make > more sense for the value passed to the script to be correct in the > first place rather than having an offset calculated first by some peice > of code then passed to the script then the script removing the offset? > IS the RTC in the squeezebox using UTC therefore the value is simply > (SqueezeboxRTCAlarmTime - (MinutesBeforeAlarmToWake * 60))? In the > SqueezeCenter web UI, the alarm times are all displayed in local time, > so the calculation has already been done somewhere. Is SqueezeCenter > not made aware of the servers RTC time, only the system local time?
There is no RTC in squeezeboxes, except for the Boom and the SBC. Both of those devices currently have no concept of timezone. They're nothing more than glorified dumb alarm clocks. Case in point: the Boom has a backup alarm. Keep your server off on a day that DST changes and the Boom will sound its backup alarm an hour off...just like any dumb alarm clock will. In perl, the language of SqueezeCenter, the "time()" function always returns a UTC epoch value, regardless of the platform...linux, windows, mac OSX, etc. The "time" you see displayed on your squeezebox is simply a call to localtime(). SqueezeCenter isn't bothering to figure offsets. Perl does that. Max's alarm functions return the next cued up alarm time as a UTC based epoch value..NOT the localtime value. SrvrPowerCtrl massages this value a bit (i.e. hacks off 5 minutes) and then spits out that value to whatever external utility is used to set the RTC wakeup alarm on the host platform. On windows, that utility is SCPowerTool.exe and it uses that UTC based time to schedule the wakeup without having to reference any local time offset from UTC. I'm not sure how this will play out on OSX as I haven't gotten to this yet on that platform, but I'll be surprised if I'll need to correct that value for local time. On linux, the utility is the scwakeup.sh script. And as your case is the first request I've received to accommodate the hardware clock being on local time, I have to believe that the majority of linux users have their hardware clocks set to UTC. The "linux & hardware clock on local time" combo is really the exceptional case here. So to me it makes sense to do this in the external script rather than in the plugin. There isn't any perl function to determine if the hardware clock is on UTC or local time anyway. So the plugin would just have to end up making the very same system calls that I'm making in the script. And that would mean putting a whole section of platform specific code into the plugin. The entire design principal of the plugin, thus far, has been to make it platform neutral. The only platform specific code present now is in the section where default settings are assigned. And that's the way I'd like to keep it. So..I can't agree with your assessment that this approach is "over engineered." To me, it makes perfect sense to keep the platform specific stuff external to the plugin. -- gharris999 ------------------------------------------------------------------------ gharris999's Profile: http://forums.slimdevices.com/member.php?userid=115 View this thread: http://forums.slimdevices.com/showthread.php?t=62339 _______________________________________________ plugins mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/plugins
