Thanks donald -- I agree, I think we should either eliminate the timezone option from the build wizard or leave it there, change the default to be timezone+localtime, with a checkbox below it that says something like: "My hardware clock is set to UTC (if you aren't sure, leave this unchecked)."
The way I've gotten it to work now, using localtime with a timezone won't cause the hardware clock to get messed up for future boots or other operating systems. This was why I suggested avoiding it previously, but now that we see some applications need the correct local timezone to function properly, I dug a little deeper to find out what was going on.
When I looked at this issue before, this was the behavior I saw:
1) Log in to fresh system - time is 10am on hardware clock and system
2) Use Slackware's 'timeconfig' script to set clock to 'localtime' and 'US/Pacific' timezone
3) System clock now reads 2am
4) say "wtf?" and reboot without saved changes
5) now I'm back in fresh system, and the time is 2am on my hardware clock and the system!
Now, if you select UTC, instead of localtime, everything appears to work as one would expect - the time gets offset (as it should) and nothing changes on a reboot. I made the faulty assumption that using localtime with a timezone other than "factory" wasn't really the way to go.
As I looked deeper more recently, I finally realized that this is what's going on (looking at a script from Puppy really helped me put the last pieces together).
1) When you start up the system, it sets the system clock from the hardware clock. Hardware clock=10am, system=10am with localtime setting
2) Run timeconfig and set to localtime and US/Pacific. Hardware clock=10am, system clock=2am.
3) When you shut down the system, it sets the hardware clock from the system clock. Hardware clock=2am, system clock=2am
4) Reboot, and system clock once again gets set from the hardware clock, which just lost 8 hours.
What should have been taking place (immediately after step 2) is another setting of the system clock from the hardware clock, which takes account for the correct time shift. This brings the system clock back to 10am so when the system shuts down, it doesn't affect the hardware clock. I've posted an updated version of the gtk-porteus-timeconfig utility for testing, the link is in this post:
http://forum.porteus.org/viewtopic.php? ... =15#p19217
Hopefully this will get us all straightened out on the issue