I'm not sure if this afflicts any other rom but it certainly afflicts pxaXrom beta4 and above.
Even if you set up the date correctly at each reboot or reset you loose the date. I'm not sure if the hardware has a hardware clock and even if it does I would not be able to write code to manage it in a reasonable amount of time ... so this is the work around I made:
I wrote a simple script in /etc/rc.d/init.d/fixdate that was able to save current time at shutdown and restore it at startup.
Unfortunately the /etc/rc.d/rc script is not working exactly as one would expect (one of the next things I'll try to fix) so I was unable to make the Kxxfixdate links in the desired runlevel directories ... but to get it working I added at the beginning of /etc/rc.d/init.d/halt a line that would run /etc/rc.d/init.d/fixdate stop.

Naturally if the PDA remains shutdown (not suspended) for a long period the time would be way off but still better that "Jan 1 1970".

Here is the script:

#!/bin/sh

. /etc/rc.d/init.d/functions

case "$1" in
start)
[ -r /var/tmp/savedate ] && \
/bin/date -s "$(/bin/cat /var/tmp/savedate)"
;;
stop) /bin/date > /var/tmp/savedate ;;
*)
echo "Usage: $0 {start|stop}"
exit 1
;;
esac

exit 0

I don't think the Zaurus has a hardware clock like a normal computer. This is why ROM's like Cacko ask you for the correct time each time you reboot. The script you provide is fine but why not run ntpd at startup? If you have internet access your time will be correct each time you reboot and will be checked periodically throughout the day.If you don't have internet access then you can use the following command to set the date:

Ntpd date only works when you are connected to net ... so ntpd would be as good as leaving the date to the default (beginning of unix time) il all other cases.
Setting the date blindly is ok but my script reloads the last date saved which I think is better. When you are connected you could just run "ntpdate -b -s <your_ntpserver>" to sync the date immediately.

In any case to your command you would at least haveto add the -s option to tell date that you want to set the date ;-)

No you dont... that command is fine....

Late

It has a rtc, but it isn't battery backed, and to make it worse the stock bootloader (and the 2.4.crappix kernel!) resets it on reboot.

Well on my 760 running r121 when I issue

date 8506131627

I get "invalid date" ... same on my slackware linux x86 ... so I guess really something is wrong with the command.
The correct format is: MMDDhhmm[[CC]YY][.ss]
So maybe

date 0613162785

would be the right command for the desigred date ;-)

date 1226142706

that is now... well when I typed it...

but the reason you get the invalid date is is because there is no 85th month... I think he put the wrong #'s in the wrong place... I wrote that it is good meaning with out the "-s"

Late

Sorry for the confusion. The date/time format I listed is correct for BSD distros, but for Linux distros it's in a different format.

Ok ...

Well whatever I still think that setting and saving with a human readable format is the most convenient.

The following command speaks for it self as to what the date is being set to:

date -s "Tue Dec 26 20:56:33 CET 2006"

And should work on all linux systems

I don't know if you're running atd, but the thread below mentions some issues you need to address if you are. The atd daemon will lock the hardware clock and prevent you from setting it properly.

http://www.oesf.org/forums/index.php?showtopic=17326#

I don't know my experience can be helpful to you or not, but it is my findings.

If you make use of the matchbox and use the 'Settings -> Date & Time' or equivalently : datentime.py in console prompt (for all other windows manager), you can adjust the date time PERMANENTLY before you have taken the battery out on reboot (i.e. warm boot the zaurus you still keep the date / time upon kernel initialization)...

Maybe there are some tricks in the datentime.py applied in housekeeping the date/time, you can investigate that further inside....

About the timezone, isn't it to be kept by the env'tal var "TZ"? I am quite confused....

No I'm not using atd and the time gets set correctly by the script I suggested.
I have'nt tryed what happens with atd active though.


Using the r121 on c760 at each reboot the time gets lost even if I use the gui tool.
I agree with KOEN ... i'ts a hardware design flaw that may not afflict all zaurii ... maybe the c1000 and c3x00 have a battery backed hardware clock.

I know that the C3100 and C3200 don't. Not sure about the c1000.

AFAIK only collie has a battery backed RTC

I believe the issue with the c760's is that there is a script that runs at shutdown... that syncs system clock to hardware clock (RTC)... well for some reason "hwclock" wasn't include in that model sets rom... I will have to talk to sash to confirm... but if that is the issue it will be included in the next release...

Late

What I'm doing is a little diffrent from what you just said, but if this workaround I'm suggesting is accepted as effective I'd be proud if it makes it to the next release.

What I'm doing is (which is just one possible workaround):
on shutdown I'm writing the current system date and time to a file, in a human readable format, so that on next reboot it can be read and used to set up the system date. This is what the scrip, I suggested at the begining, does respectively with the start and stop options.

In order to avoid having to modify /etc/rc.d/rc script you could add the necessary stuff to the "start" case so that it could run properly with the kill stuff in runlevels 0 and 6 (I guess it boils down to creating some file in the var tree). I do not want to do this because I'm concidering writing BSD style init scripts for my c760 as soon as I get some other things straight.

PS: yes I love Slackware

I spent a little more time thinking on this:
The c7xx/860 do have hardware clock (or at least something that linux recognises as RTC), I've no idea why on the 2.6 open kernels it still gets reset on reboot (this is not a good thing to do).
The sole porouse ot the hardware clock is to keep time while linux is not running, but if when linux starts it resets the hardware clock before reading it what's the point.
This may be dew to the fact that the content of the clock may be unpredictable if it suffered from power loss (but if the hwclock designer was smart it should self reset itself to unixepoch {or some other fixed time} when powered up)... I'm not sure .... any one konw why it gets reset on reboot ?

Any way it would be nice if one could read bothe from a saved file and from hardware clock, then set the system clock to the newer of the two.

Anyone know why the hwclock feature has been removed from pdaXrom's busybox ?

I had a talk a while back with the sa1100-rtc kernel driver writer ... and apparently there is not much that can be don to avoid the reset upon reboot ... (hope to find the time to confirm this from pxa tech doc in the mean time I'll take his word for it).

What I found out is that altough the /etc/apm stuf has become mostly obsolete with 2.6 kernels, apmd can be made do similar things ... so there is a way to keep a realtively updated system time backup file (by updating it every suspend and resume).