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

Marc Leclerc marc-leclerc at signaturealpha.com
Sat May 15 04:30:47 UTC 2010


Thanks for your answer, the system I am working on is an ARM Linux based 
embedded board. the device is intented for electric utilities and we 
must meet good time precision, this device requires 1ms precision but 
our next one will require micro second precision therefore I am going 
for the bigger goal right away. There will not be any NTP server on the 
network, they are rather looking in a mid-future at the precise time 
protocol. My first intention was to use NTP with our on board GPS but it 
turns out it aint supported and as time grows short going right to the 
source may be my only way out. The standard (IEC-61850) demands time as 
UTC and the GPS does support giving UTC time, only thing it gives it as 
separate entries (Year, Month...). Since the time given by the GPS 
already accounts for leap seconds would the formula you sent still give 
me proper time if I am to be compared to other system

Thanks again

On 2010-05-14 23:18, Garrett Wollman wrote:
> 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 */
>
> 	putenv("TZ=");
> 	tzset();
> 	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.
>
> -GAWollman
>    




More information about the questions mailing list