Is ths one of those questions where you ask a nominally valid question,
but since you don't know what you are talking about you get lots of
A "real time clock" is the thing that interrupts the computer every so
often, and the software that counts those interruptions.
In the old days, you had to set the time when you started the computer,
because it didn't know what time it was, just the time relative from that
Later, a hardware clock was added, so the computer could poll that clock
and get the time by itself. This actually keeps time by a clock and a
bunch of counters, so the computer reads the absolute time. But the
computer only reads the hardware clock on booting up, or when you tell it
to read the hardware clock, otherwise it uses the RTC to keep track of the
time. That's why I'd lose time on my Radio Shack Color Computer decades
ago when reading floppy disks; disk operations turned off the interrupts
because the routine needed to work fast, so the clock would lose time due
to lack of updates.
Since Linux is very interrupt driven, I find it hard to believe that Linux
can run without also keeping track of the time.
If the Raspberry Pi really does not have a hardware clock to keep track of
the time when it's turned off, then all you need to do is manually set the
time once you turn on the computer. The utility has to be there, it has
is lost. > It's a universal truth that you'll want to get the most-recent
Or rsync - may not be installed out of the box, but its definitely
included in the standard package set (use apt-get or the equivalent GUI
command to install it. Its my favourite backup because, after the initial
run, its fast.
Speed ups of around 30-70 times are typical: it does the minimum work
needed to make a backup disk or SD card identical to the current state of
the source device and has clever tricks for doing minimal work on large
files (databases, binaries etc). You'll probably want to use a cycle of
at least two backup cards: I do exactly that using a cycle of two USB
hard drives which are kept offline in a fireproof safe when not being
used to make a backup or (much more rarely) to recover after an old disk
martin@ | Martin Gregorie
gregorie. | Essex, UK
No. A real time clock is a little clock chip on the computer which
actually counts the seconds and keeps track of the actual date and time
as well. It is run off a battery and still works even if the computer is
shut off, unplugged and (for a laptop) the main battery removed.
PCs have had RTC for a long long time now.
What you call the hardware clock is more usually called the RTC.
The system clock is what you seem to call the RTC. The rPi has a system
clock. It has no RTC.
Yes. Unfortunately linux (usually) does not have a program which asks
for the current time when switched on.
Files are transfered to OP's rPi on a USBstik, before that is carried to
a location which has no electricity-supply. It's in a shoe-box with a 6V
accumulator. For TextToSpeech; no display; only control is on/off switch.
Setting the date at each boot, on a device which HAS a keybrd+display
is lame - too.
This problem is for inventive minds, not a hi-tech solution via your
& how does the OP get then from the stick to the PI?
is there some kind of automated script in lace or does he have to issue a
The solution from the inventive minds is already available
there are a number of very small, very cheep RTC add on boards for the PI
Therefore the options are simple & in order of preference.
1) but a clock module
2) if manual sync then set the time manually before performing the sync.
3) if an auto script modify the auto sync script to set the time to that
of the newest file on the stick, or that of the destination directory
(whichever is the later) before performing the sync. the time will be
wrong but usable wrt the time stamps of the files.
Aha it is you! We should have known that, and just ignore you.
Anyway, when you have designed and built a system that requires real
time and has no network, your selection of the Raspberry Pi has
been WRONG, because it does not include an RTC.
Fortunately for you, RTC modules are available as an add-on, so you
can still save your butt.
Only from August 1984 when IBM introduced the AT (successor to the XT
and the earlier PC) based on the 80286 CPU with the expansion bus
slots extended from 8 bit to 16 bit data buses and an extra 4 bits on
top of the existing 20 bit address bus.
Prior to the AT, the original PC and XT motherboards didn't include a
RTC. However, a lot of add in peripherals such as CGA and VGA, memory
expansion cards and Multi-I/O adapters (required to connect floppy
disks, modems, printers and hard disks) started appearing with RTC
chips included, along with, typically, a lithium coin cell holder).
The RTC became such a ubiquitous feature of add on adapter cards that
it wasn't unusual to see a PC or XT with as many as 3 such RTCs to
choose from! In fact I myself reached such a state of 'surplus RTCs'
with my early home assembled PC (made from 'scrapped' parts) around
1984/85 due to this proliferation of RTCs being "Free with every 8 bit
adapter!" effect. :-)
IBM put paid to this by including the RTC on-board in their then
latest AT motherboard specification. The CMOS RTC with its 70 odd
spare 8 bit registers were able to amply serve the needs previously
supplied by the three or four 8 way dip switches required to
configure the hardware (presence and number of floppy disk drives, the
amount of installed ram and other junk) which freed up a significant
chunk of MoBo real estate as well as allow "The CMOS" to be configured
via software, initially from a special setup program on a floppy but
very swiftly incorporated into the BIOS rom via a hot key during the
POST sequence so that all PCs _except_ the crap made by Compaq, could
be configured _without_ the need for a special floppy disk setup
In the meantime, MSDOS would always prompt for the date and time on
every boot _unless_ an AUTOEXEC.BAT file was found on the boot disk.
It was enough for such a file of that name to be present, even if it
was empty, to suppress MSDOS's ever present request for the date and
This quite neatly saved the early users of PCs who weren't bothered
about date/time stamps from having to type these details in after
every crash or install induced reboot, typically games players, whilst
at the same time, allowing this question to be explicitly re-submitted
and then answered by the RTC supplied interface software when such an
RTC module was available.
All subsequent PCs (essentially AT and the ATX variant) retained
timer chip compatability with the original PC where the OS would
program a timer to produce a timer interrupt (18.1818 times per second
for the OS's system time function, AFAICR).
The hardware RTC merely supplied the initial settings on each reboot
and was normally never consulted again unless a specific software
request was made (manually inputting the date and time from a dos
prompt would automatically update the RTC as well as the system time
(at least for the AT class of PC hardware - I'm not so sure about the
earlier PC standard with its add-on RTC though).
Well, since Linus didn't attempt to port a version of Unix onto a PC
until Intel finally got off their fat backsides to produce their first
decent CPU in the form of the 80386 (which every subsequent intel CPU
has been based upon), the integrated RTC has always existed in the
history of X86 versions of Linux. The lack of such an integrated RTC
would seem to be unique to the ARM SoC processors used by R-Pis and
Historically, for all the PC versions at least, there hasn't been any
need to automatically prompt for such user information on every reboot
as was the case with MSDOS. However, it's quite simple to include such
a request in a startup script, including initiating a date/time update
from an externally added RTC module.
IMO, the best "Algorithm" is to use an add on RTC module and add the
appropriate time setting requests to the startup script if reasonably
accurate time is required on a R-Pi that stands in total isolation
from the internet or any other time setting source such as MSF Rugby
or a GPS receiver.
Relying on the latest date of a regularly updated file is a piss poor
workaround at best, only being slightly better than nothing at all. If
the system date/time has any importance at all (at least to the extent
of asking this question), you really aught to fit an RTC module if no
alternative source of accurate time setting is available.
Of course you now tell us what the situation is.
And you ignore suggestions-- eg look into /var/log/ and find the most
recent date, and use that or say 5 min later, to set your clock on
bootup. Or as others have noted apparenlty the RPi saves the current
time to a file periodically. Use that as the new time when the Pi boots
up. Or put a cron job to run every minute to save the current time to a
file, and use that at bootup.
All of these suggestions have been made and you spend your time
attacking someone who had not idea what your setup was, because you
never told anyone. It does look like you are a troll.
Is that because, it sets a timer, from the fake-hwclock.data when it boots
and it adds that to fake-hwclock.data when it halts-properly?
File: fake-hwc~ck.data ==
-> date == Tue Mar 3 09:36:43 SAST 2015
Perhaps if I translated it to I could understand that?
Put into root's cron
0-59 * ** * date +%s >/etc/currenttime
And into a startup script (eg in /etc/init.d with a link from the
date -s @`cat /etc/currenttime`
You want this happening before cron starts up so it should be early ( a
low number in the link in /etc/rc?.d) Eg
ln -s /etc/init.d/settime /etc/rc3.d/S20settime
if you called that script settime
The above is a very abreviated description. Look at other scripts in
/etc/init.d to find the appropriate format etc.
You could also try adding 60 or more to the "currenttime" as an estimate
of the time the computer was shut off, since it takes time to shut down
and come back up. But of course with no rtc you cannot know how much
time has passed.
I have no idea what format fake-hwclock.data is in. It would make more
sense for it to be seconds after epoch rather than a human readable
string, but who knows.
Very true, but not practical for somebody living in Republiek van Suid-Afrika.
According to Wonkeypedia
"A noon gun has been fired in Cape Town, South Africa, since 1806.
The gun is fired daily from the Lion Battery at Signal Hill."
Apparently at one time there was
2.500 MHz ZUO Olifantsfontein, RSA
5.000 MHz ZUO Olifantsfontein, RSA
4.291 MHz ZSC Cape Town, RSA
8.461 MHz ZSC Cape Town, RSA
but the site
suggests that these stations are no longer in operation.
So alternative sources of time could be DVB-t (using a DVB-t card in a PCI,
grab the time from that and use it to seed the LAN ntpd) or in a similar
manner from DVB-s if a satellite dish is available, or from a GPS handheld
Probably all of these suggestions will be rejected by Chris Glurr on
account of being Walmart-credit-card solutions because they involve
some additional cost, so that leaves just the Noon Gun solution, if
he can hear it, way out on the veldt.
Yes, down in ZA I'd probably go for a GPS receiver, but one of the
'blind' receivers, e.g a Garmin GPS35 or GPS18, rather than a handheld.
These output an NMEA 183 sentence every second, typically at 4800 baud by
default but are configurable to higher speeds if required. The GPS35-HV
model is set up to communicate over a single D-9 connector and wants a
12v power supply. From memory the other models use TTL levels.
You can find blind GPS receivers on eBay and can probably find used ones
in ZA - ships chandlers or yacht clubs would be good places to start
But you're right: Mr Glurr may not agree about the benefits of GPS as a
martin@ | Martin Gregorie
gregorie. | Essex, UK