Ignoring the Year 2000 issues with gmtime, it states in the Intel Fortran Libraries reference that gmtime returns this:
tarray(1) Seconds (0-59)
So, does it not handle leap seconds?
Thanks,
Chris
連結已複製
8 回應
My reading of the ANSI C standard shows this:
The range and precision of times representable in
clock_t and time_t areimplementation-defined. The
tm structure shall contain at least the following members,in any order. The semantics of the members and their normal ranges are expressed in the
comments.
268)int tm_sec; //
seconds after the minute [0, 60]int tm_min; //
minutes after the hour [0, 59]int tm_hour; //
hours since midnight [0, 23]int tm_mday; //
day of the month [1, 31]int tm_mon; //
months since January [0, 11]int tm_year; //
years since 1900int tm_wday; //
days since Sunday [0, 6]int tm_yday; //
days since January 1 [0, 365]int tm_isdst; //
Daylight Saving Time flag268) The range [0, 60] for
tm_sec allows for a positive leap second.This seems to be consistent with what is in time.h,.
Message Edited by cjosefy on 06-07-2005 10:44 AM
Well the declaration of gmtime in time.h say [0-60] on my RHEL 3 machine. However, I don't know how the routine would now that there is a leap second. I just wanted to know if it was possible to return a 60 to the FORTRAN routine. My reference from above is
ISO/IEC 9899:TC2
Committee Draft May 6, 2005 WG14/N1124The ANSI C Programming Language by Kernighan and Ritchie says it can be [0,61]
Message Edited by cjosefy on 06-09-2005 01:50 PM
From my reading, it seems that the time functions get the time from the time zone files on the system. POSIX standards say to ignore leap seconds, and that it the default behavior on Linux. However, there are time zone files with the leap seconds in them, and if your system uses those, then your functions still work but are not POSIX compliant. For example, on my system the time zone files /usr/share/zoneinfo/GMT doesn't have leap seconds, but /usr/share/zoneinfo/right/GMT does.
