Why is a signed integer used to represent timestamps? There is a clearly defined start at 1970 that's represented as 0, so why would we need numbers before that? Are negative timestamps used anywhere?
Unix Timestamps – Why Unix Stores Timestamps in a Signed Integer
timestamps
Related Solutions
Interesting problem, Not sure I've ever tried to do this. But I have notice the timestamp you are talking about and I have always belived it to be seconds since bootup.
In my syslog I have on my server, I have:
Jan 10 19:58:55 wdgitial kernel: [ 0.000000] Initializing cgroup subsys cpuset
Jan 10 19:58:55 wdgitial kernel: [ 0.000000] Initializing cgroup subsys cpu
Jan 10 19:58:55 wdgitial kernel: [ 0.000000] Linux version 2.6.32-21-server (buildd@yellow) (gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) ) #32-Ubuntu SMP Fri Apr 16 09:17:34 UTC 2010 (Ubuntu 2.6.32-21.32-server 2.6.32.11+drm33.2)
Jan 10 19:58:55 wdgitial kernel: [ 0.000000] Command line: root=/dev/xvda1 ro quiet splash
I would imagine this is fairly consistent among most Linux distro's as this is the kernel spitting out it's stuff.
And here I have the date along with the timestamp.
To answer the question i make an assumption:
You are using rsync locally, transferring from a mounted SD-card to backup space
MMC are formatted with FAT-filesystems, so its always useful to set --modify-window=1 because FAT-filesystems store timestamps in a 2 second resolution.
man rsync gives the option --size-only which ignores the last-modified flag of the files. So only files with modified size, e.g. edited ones will be synced.
Another option would be to set the option --modify-window to the time difference between the two timzeones in seconds.
e.g. for 2 hours use modify-window=3660 if there is a 1 hour difference
maybe the is a problem with your UTC setting.
You can check if your hardwareclock is set correct by typing date --utc
Xour softwareclock is given by date.
The value should have the same difference as your local timezone to Greenwich Mean Time.
Your hardwareclock should always be set to UTC so all timestamps are set correct even when you change timezones(softwareclock).
If the UTC time is not correct, check if it ist set correct in your BIOS. If not, correct it.
If it is set you can check /etc/default/rcS. The should be the following line (Ubuntu 12.04)
#assume that the BIOS clock is set to UTC time (recommended)
UTC=yes
Best Answer
Early versions of C didn't have unsigned integers. (Some programmers used pointers when they needed unsigned arithmetic.) I don't know which came first, the
time()function or unsigned types, but I suspect the representation was established before unsigned types were universally available. And 2038 was far enough in the future that it probably wasn't worth worrying about. I doubt that many people thought Unix would still exist by then.Another advantage of a signed
time_tis that extending it to 64 bits (which is already happening on some systems) lets you represent times several hundred billion years into the future without losing the ability to represent times before 1970. (That's why I oppose switching to a 32-bit unsignedtime_t; we have enough time to transition to 64 bits.)