Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I have looked at the man page and experimented with a few things, but I haven't been able to figure this out.
Can anyone tell me why this works:
Code:
date -u +%T -s "21:25:26"
But this doesn't:
Code:
date -u +%H%M%S -s "212526"
Basically, I want to be able to set the UTC time to a string without having any punctuation. It seems like the second command should work, according to the man page and everything I have read, so I am a little stumped.
This isn't a very serious issue, it is really just something I was playing around with and thought was odd. What I am trying to do is set the system time to the UTC time string that is returned from my GPS every second.
For example, this command reads the NMEA output of the GPS, and returns the UTC time when it is reported (exactly once per second):
I want to send that returned string into "date" as quickly as possible, I don't want to waste milliseconds doing any string operations adding in colons and the like. I also need to get "date" to accept nanoseconds in the format string (%N), but one step at a time.
NOTE:
I am aware this is not the proper way to do this, and like I said, this was more of a experiment than anything. The right way to get PPS accuracy on a Linux machine requires kernel patching and some userland utilities, but I wanted to see how close I could get doing it by hand.
The last example looks promising, assuming it works in UTC also:
Code:
Set the date to July 1 (0701), 4 a.m. (0400), 2005 (05):
date 0701040095
I could pull the day, month, year from the local clock before polling the GPS, and it looks like the optional .ss would let me provide the seconds.
The man page for "date" seems to indicate that you can tailor your input the same way you can do for output:
Code:
-d, --date=STRING
display time described by STRING, not `now'
.......
-s, --set=STRING
set time described by STRING
But maybe there are inherent limitations to input that isn't mentioned? I will play around with this a bit and see if that works, I think I can get close enough if I pre-fetch the date information and just insert that with the UTC satellite time. The nanosecond field shouldn't matter as the GPS outputs the time exactly on the second, and frankly, getting down to nanosecond accuracy in a Bash script is probably beyond wishful thinking.
With my Garmin 18 LVC the reference is the one-pulse-per-second output pulse immediately preceding the GPRMC sentence, or whichever sentence is first programed. You can determine the RS-232 transmission latency but it will difficult to determine latencies due to OS.
Well, this actually seems to get pretty close. It may actually be a little closer than my stratum 3 NTP server.
The script:
Code:
#!/bin/sh
# Hackish way to set system time to GPS PPS
# Pre-fetch date info
DATE="$(date +%m%d)"
YEAR="$(date +%y)"
# Pause and return UTC time string as close to PPS as possible:
UTC="$(awk -F, '/\$GPGGA/ {print $2; exit}' /dev/rfcomm0 | cut -c 1-6)"
TIME="$(echo $UTC | cut -c 1-4)"
SECONDS="$(echo $UTC | cut -c 5-6)"
# Put it back together and set the time
date -u $DATE$TIME$YEAR.$SECONDS
To compare the live time from the GPS to system time, I use the following command:
So this shows system time lagging satellite time by a very slim margin, which I assume is coming from the script itself, plus the inherent latency over the Bluetooth link.
Interestingly, running that same command on my NTP server:
It would appear that the time is several hundred milliseconds off when set from the Internet (which of course is not very surprising).
While this is a very rough experiment, I wonder what type of results I would get if I ran this script every 15 or 30 minutes on my NTP server rather than pulling time from a stratum 2 server. Perhaps I could even improve the execution speed of this script a bit, I am sure there is a better way to separate the UTC string into HHMM and SS, but I can't think of how.
Would the + part be ignored, since that's for how the date is outputted, not inputted? Beyond that I never really figured out date for setting the date/time. But it does work if you input date and time in two separate commands
date -s "20090921"
date -s "12:31:30.123"
Although I typically just do an
ntpdate time-b.nist.gov
Unless I don't have an internet connection, where I have to do the previous date method.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.