Compartilhar via

A Cure for Daylight Savings Time Amnesiacs

  • Artigo

In the 1993 movie Groundhog Day, Bill Murray plays the role of Phil Connors, a man who goes to sleep every night and keeps waking up on Groundhog Day, as if a capricious Creator keeps turning the hands of time back to the same spot each morning. The story plot revolved around Phil’s frustrated attempts to return to normal time and a normal life.

Windows XP Embedded Devices using EWF-RAM to protect the system volume can experience a similar amnesia problem during Daylight Savings Time (DST) transitions. Each time a device that is so configured reboots, the system forgets (by design) all state changes to the system volume. This unfortunately includes registry changes that indicate whether DST has already occurred. Meanwhile, the BIOS CMOS memory on the motherboard faithfully remembers the time and date. 

When Windows XPE boots up and discovers that the date has switched into official DST, it automatically adds an hour to the time of day and then sets a registry entry so it can remember that it has “fallen forward”. Unfortunately that registry entry information is lost upon subsequent boot when EWF or FBWF are used. The next time the device reboots, it will increment the time of day another hour, because the (registry-based) knowledge about having previously switched into DST is lost. As a result, there will be a creeping forward of time. Note that if the system image was created with DST turned on, the time of day will decrement backward an hour at a time, after switching out of DST (into winter).

The EXE file on the MSDN site is a care package that offers two possible workarounds to this problem. Please read the contained README.TXT for details. NOTE: This workaround has not been successfully tested for use with FBWF.

This code sample is subject to the terms of the Microsoft Limited Permissive License (Ms – LPL) . If you do not agree to these terms, do not use the code.

- Mark

Comments

  • Anonymous
    April 25, 2007
    Back in november 2006 this topic (Registry Filter Tips) was discussed and then seemingly dropped. Specifically the post dealt with using the Registry Filter to filter additional keys. The thread ended with a similar list of workarounds. What I am wondering is, has there been any more progress on the topics. It seems to me if the DST state is addressed before the Registry Filter cmoes online, you should be able to resolve the conflict by making the Time service dependant on the registry filter service.   I don;t know if anyone else has been bitten by this quite the way I have but I really do need to find a real solution, not just a workaround.

  • Anonymous
    April 25, 2007
    Hi Dale, Good call. Unfortunately, the DST info is loaded during boot before the regflt is enabled so we're not able to filter these keys. It's on the list of additional features to dig into and see if we can find an alternative solution including loading the filter driver sooner if possible. -andy

  • Anonymous
    April 27, 2007
    In the Work around given for EWF, the script commits the changes then reboots. It seems that when using fbwf you would not have to commit right away, is this correct? Also using FWBF because you can commit any file directly you should be able to simply commit the registry file by itself.? I have been working on an equivalent solution for the FBWF. I have opened source of the dst_detector and see that it references a key in HKLM. So based on this I assumed that the SYSTEM Hive needs to be committed. This does not work fully. The dst_detector app identifies when the dst state changes and commits the c:windowssystem32configSYSTEM but on the subsequent reboot, the time advances another hour. Is it know exactly which files must be committed for the dst state to be maintained? The EWF workaround skips this knowledge as all file are committed.

  • Anonymous
    May 08, 2007
    Dale, Can you add c:dst.txt to the fbwf exclusion list and retry? Make sure the drive is correct location of the file. thanks