[ntp:questions] Converting from Y-m-d h:m:s

Garrett Wollman wollman at bimajority.org
Sat May 15 03:18:03 UTC 2010

In article <4BEDCED4.2030900 at signaturealpha.com>,
Marc Leclerc  <marc-leclerc at signaturealpha.com> wrote:

>is there any consideration when converting GPS/UTC DateTime YYYY MM DD 
>HH mm ss to a timespec value to set the system clock, I though I could 
>find a function to do this easily. Do the leap seconds in UTC have to be 
>considered when setting the system wall time

If you have a POSIX system, the leap seconds must be *ignored*.  POSIX
requires that "broken down time" in UTC be convertible to time_t
values using a simplistic formula that aliases positive leap seconds
to the following second (i.e., it cannot distinguish between 23:59:60
and 00:00:00) and double-counts negative leap seconds (conveniently,
we've never had any).

IEEE Std.1003.1-2001 (the only version I have conveniently to hand)
supplies the following definition of "Seconds Since the Epoch":

	tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 +
	    (tm_year-70)*31536000 + ((tm_year-69)/4)*86400 -
	    ((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400

Using only standard library routines, you could also do:

	time_t t;
	static struct tm tmzero;
	struct tm tm = tmzero;

	/* fill in struct tm */

	t = mktime(&tm);

This would work even on systems that do not use the broken POSIX
definition (although such are few and far between).  If your system
has it, the timegm() function will do the same thing as the last three
lines but without the side effects on the environment.

Garrett A. Wollman    | What intellectual phenomenon can be older, or more oft
wollman at bimajority.org| repeated, than the story of a large research program
Opinions not shared by| that impaled itself upon a false central assumption
my employers.         | accepted by all practitioners? - S.J. Gould, 1993

More information about the questions mailing list