[Fwd: Re: EPICS_TS_MIN_WEST]

[Marty Kraimer <mrk@aps.anl.gov>]

Jeff,

You may find the discussion about leap seconds interesting.

Marty

--- Begin Message ---

Subject:	Re: EPICS_TS_MIN_WEST
From:	Marty Kraimer <mrk@aps.anl.gov>
To:	Andrew Johnson <anj@aps.anl.gov>
Date:	Fri, 03 Jan 2003 07:21:49 -0600

Andrew Johnson wrote:

Marty,

The AppDevGuide still lists the above in its index, and has no description of what EPICS_TS_NTP_INET does. I think it would be a very good idea for the way in which we handle time to be documented - at least somewhere should say that we use the vxWorks SNTP client. I can't find anything much about time other than the too-detailed description of the epicsTime class and the stuff about TSconfigure.

I will look at the code and update the AppDevGuide

- Andrew

PS: Does CA currently send timestamps in the server's local timezone? If true that doesn't seem like a good idea (unless the server also tells each client its timezone at connection time), it might not be long before it starts to cause problems...

No,

Timestamps are always UTC time relative to the EPICS epoch, not including leap seconds. It is only when time stamps are converted to something else that needs local time. For the gory details see epicsTime.

By the way the single unix standard rational has a nice discussion of why posix time stamps do not take care of leap seconds. I have included the discussion below.

Marty

Seconds Since the Epoch

Coordinated Universal Time (UTC) includes leap seconds. However, in POSIX time (seconds since the Epoch), leap seconds are ignored (not applied) to provide an easy and compatible method of computing time differences. Broken-down POSIX time is therefore not necessarily UTC, despite its appearance.

As of September 2000, 24 leap seconds had been added to UTC since the Epoch, 1 January, 1970. Historically, one leap second is added every 15 months on average, so this offset can be expected to grow steadily with time.

Most systems' notion of "time" is that of a continuously increasing value, so this value should increase even during leap seconds. However, not only do most systems not keep track of leap seconds, but most systems are probably not synchronized to any standard time reference. Therefore, it is inappropriate to require that a time represented as seconds since the Epoch precisely represent the number of seconds between the referenced time and the Epoch.

It is sufficient to require that applications be allowed to treat this time as if it represented the number of seconds between the referenced time and the Epoch. It is the responsibility of the vendor of the system, and the administrator of the system, to ensure that this value represents the number of seconds between the referenced time and the Epoch as closely as necessary for the application being run on that system.

It is important that the interpretation of time names and seconds since the Epoch values be consistent across conforming systems; that is, it is important that all conforming systems interpret "536457599 seconds since the Epoch" as 59 seconds, 59 minutes, 23 hours 31 December 1986, regardless of the accuracy of the system's idea of the current time. The expression is given to ensure a consistent interpretation, not to attempt to specify the calendar. The relationship between tm_yday and the day of week, day of month, and month is in accordance with the Gregorian calendar, and so is not specified in POSIX.1.

Consistent interpretation of seconds since the Epoch can be critical to certain types of distributed applications that rely on such timestamps to synchronize events. The accrual of leap seconds in a time standard is not predictable. The number of leap seconds since the Epoch will likely increase. POSIX.1 is more concerned about the synchronization of time between applications of astronomically short duration.

Note that tm_yday is zero-based, not one-based, so the day number in the example above is 364. Note also that the division is an integer division (discarding remainder) as in the C language.

Note also that the meaning of gmtime(), localtime(), and mktime() is specified in terms of this expression. However, the ISO C standard computes tm_yday from tm_mday, tm_mon, and tm_year in mktime(). Because it is stated as a (bidirectional) relationship, not a function, and because the conversion between month-day-year and day-of-year dates is presumed well known and is also a relationship, this is not a problem.

Implementations that implement time_t as a signed 32-bit integer will overflow in 2038. The data size for time_t is as per the ISO C standard definition, which is implementation-defined.

See also Epoch .

The topic of whether seconds since the Epoch should account for leap seconds has been debated on a number of occasions, and each time consensus was reached (with acknowledged dissent each time) that the majority of users are best served by treating all days identically. (That is, the majority of applications were judged to assume a single length-as measured in seconds since the Epoch-for all days. Thus, leap seconds are not applied to seconds since the Epoch.) Those applications which do care about leap seconds can determine how to handle them in whatever way those applications feel is best. This was particularly emphasized because there was disagreement about what the best way of handling leap seconds might be. It is a practical impossibility to mandate that a conforming implementation must have a fixed relationship to any particular official clock (consider isolated systems, or systems performing "reruns" by setting the clock to some arbitrary time).

Note that as a practical consequence of this, the length of a second as measured by some external standard is not specified. This unspecified second is nominally equal to an International System (SI) second in duration. Applications must be matched to a system that provides the particular handling of external time in the way required by the application.

--- End Message ---