rickwookie;416123 Wrote: > I still don't get the bit about since we've established that Windows > keeps the RTC in local time, so something must be referencing a local > time offset (or is it the Windows API or something like that?). Yes, something like that. Even though windows machines keep the hardware clock set to localtime, _everything_ that happens under the hood happens in UTC. It just gets converted to local time when things get displayed to the user. So, for instance, all file dates and time on NTFS are stored as UTC values. You can see one instance where problems crop up with this scheme in windows: take a file on your NTFS formatted hard disk and copy it to a FAT32 formatted usb drive on October 30th. Look at a directory listing of the two files...they will have identically reported file modification times. Wait a day and look again on November 1st: now the file modification dates are reported as being an hour different. That's because FAT32, unlike NTFS, stores file times in local time. Windows converts the UTC filetime to localtime when it copies the file. See more on this here: http://en.wikipedia.org/wiki/NTFS#Compatibility_with_FAT
So, when SCPowerTool schedules the system wakeup by setting a timer using one of the windows kernel functions, it sets that timer using a UTC time value. The only conversion that SCPowerTool performs is to translate the UTC linux epoch value from the 32bit "seconds since January 1, 1970" to the 64bit Windows UTC epoch value of "milliseconds since January 1, 1601." But again, the windows kernel expects the timer wakeup time to be expressed in UTC, not local time. There are utilities out there that will wakeup a windows system from standby, notably WOSB.exe, that do take local times as arguments. But it's those utilities that are having to convert that local time into a UTC system time. I already do the (in my view) "over engineered" conversion of UTC time to local time to support WOSB.exe for folks who would rather use that utility than my SCPowerTool.exe. Perhaps I should add parameter type to the wakeup command parser. Right now, I'm supporting the following types: -Enter the full path and any cmd line arguments to the system wakeup command here. If you include "%d" as a cmd line argument, SrvrPowerCtrl replaces this with the unix epoch UTC date/time value for the wakeup time, e.g. "1230789300". If you include "%s", then SrvrPowerCtrl substitutes a date/time string in the local time, e.g. "01/01/2009 05:55:00". "%f" gets translated into the system local time "short-date" format in your locale; "%t" gets translated into the system local time "time" in HH:MM:SS format.- So.....ok, I've just convinced myself of your argument. Since I'm already doing local time conversions to support WOSB.exe, I might as well support UTC epoch time to local epoch time as well. I just need to write another simple conversion routine. I'll add this to the next beta version, due out shortly. We'll make the parameter "%l" for local epoch time. How does that sound? -- 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
