1. It has been more common than we would like to find times that
are off by an hour, 5 hours, or 6 hours within the control
system. These errors are related to confusion about timezones:
Coordinated Universal Time (UTC)
Greenwich Mean Time (GMT) - obsolete (more on this later)
Central Standard Time (CST)
Central Daylight Time (CDT)
a. Confusion about CST vs. CDT - Many older date formats did
not provide an explicit timezone. Therefore, with such
formats one can not distinguish the repeated local times
that occur in the first hour after the transistion back to
standard time each Fall. With a timezone one can tell the
the difference because the first occurence is in CDT but
the second is in CST. Nearly all clib routines for date
conversion use ":" vs. ";" to make this distinction.
b. Historical use of local time - The VAX/VMS machines
used local time pervasively not just for user interface
aspects. This includes the semantics of the time_t
values. Because of the volume of software much software
still expects such local time_t semantics. Such time_t
values don't increase uniformly by 1 each second. See
convert_seconds_c for a discussion of local time_t vs.
UTC time_t. The Sybase database also used local time
historically. See intro_database for more details and
techniques to use UTC times for new DB fields.
2. Time systems used within the ACNET Control System
a. broken down time systems - years, months, days, etc.
a. Central Standard Time (CST)
A timezone 6 hours behind UTC. Stated another way CST's t=0 moment
is 6 hours later than UTC's t=0 moment. UTC will be discussed later.
b. Central Daylight Time (CDT)
A timezone 5 hours behind UTC. Stated another way CST's t=0 moment
is 5 hours later than UTC's t=0 moment.
c. Coordinated Universal Time (UTC)
The definition of UTC is somewhat complicated (see
systems-of-time). It is a replacement for Greenwich Mean Time
(GMT) which is considered obsolete by time experts, e.g., the
individuals at the U.S. Naval Observatory (USNO) and the
National Institute of Standards (NIST). But in the ACNET
Control System and Linux in general the distinction between UTC
and GMT is hard to understand, keep, or notice. E.g., Linux has a
gmtime_r() which despite its name claims according to the man page
to convert time to UTC but the value it actually places in tm_zone
is "GMT" anyway. In addition, by experiment neither Java nor
C/C++ on our Linux systems handles UTC's leap seconds correctly.
This experimental determination was made using the code in
services/time_experiments. So the error bars on our operating
system's conception of time exceeds the distinction between UTC
and GMT. For our purposes both are a timezone 6 hours ahead of
CST and 5 hours ahead of CDT. Of course, since CST and CDT were
defined above in terms of UTC this is quite circular. UTC is
really defined in terms of atomic clocks, the Earth's rotation,
and other complexitities that we don't really need to understand.
d. Local Time at FNAL
A combination of CST and CDT. CST and CDT are reasonably sensibly ways
to specify time when used consistently. The difficulty comes from
switching back and forth between them. It is of particular difficulty
that the date of the transistions are a subject of ever-changing
legistation and as a result depend on the year.
b. single unit time systems - elapsed seconds/milliseconds
a. Elapsed time since the Epoch (1/1/1970 midnight UTC)
a. Both Java, e.g., java.util.Date, and Linux C/C++, e.g.,
ctime(3), define "the Epoch" to be 1/1/1970 midnight UTC/GMT.
b. Java and C/C++ agree on "the Epoch" but use different units.
a. Java uses milliseconds since the Epoch.
b. C/C++ uses seconds since the Epoch. C/C++ also has time structures
that augment seconds with milliseconds, microseconds, or
nanoseconds since the last second.
a. time_t just seconds since Epoch
b. struct timeb time_t plus milliseconds since increment of time_t
Please don't use struct timeb it is associated with the obsolete
ftime() routine. It includes undefined members pertaining to
timezone and DST that might be assumed incorrectly to have
accurate values. See man ftime(3).
c. struct timeval time_t plus microseconds since increment of time_t
d. struct timespec time_t plus nanoseconds since increment of time_t
The actual resolution beyond seconds depends on the system. On our
Linux systems nanoseconds is just microseconds times 1000.
b. "ctime", i.e., time_t values
a. This unit of measure is named after the function of the same name, which
takes a time_t as its only argument. However, many routines on Linux
expect a time_t argument not just ctime. In addition the semantics of
ctime(), etc. changed. On VAX/VMS ctime was non-linear, but on Linux it
is linear, see comments under old choices. This difference leads to
individuals not all meaning the same thing when they use the term
"ctime". In addition the t=0 moment for "ctime" on the VAX/VMS machines
was 1 Jan 1970 midnight CST, but on the Linux it is 1 Jan 1970 midnight UTC.
b. As a result the following terminology is established:
Local ctime - reflects semantics of the now retired VAX/VMS machines
UTC ctime - reflects semantics of the current Linux machines
Local ctime is very common for historical reasons, but UTC ctime is
prefered for new uses. See convert_seconds_c for detailed explanation
of the difference between the two.
c. Clinks (ACNET time)
a. The time of an event in clinks is the total elapsed seconds between the
event and 1 Jan 1972 midnight CST. Note that differs from seconds since the
Epoch because the year has changed from 1970 to 1972 and timezone from
UTC to CST.
b. Because of VAX/VMS's use of local time, clinks on the VAX/VMS was not
actually linear. (See discussion above about "ctime".) This was noticed
during the VMS to Linux migration and was as far was one can tell fixed
except perhaps for persistent data. The historical clinks_handle_dst_c
routine was removed from clib's clinklib.cpp on 1 June 2009.
3. Of particular importance is using date and time well within the database. Please
see intro_database for how to use UTC for DB datetime fields.
Official US Time from NIST
Orgin of UTC and demise of GMT
UTC, UT1, and the demise of GMT
Leap seconds and years from NIST
Screen capture of leap second from www.time.gov in Central timezone
Leap seconds when present are at midnight UTC.
Subscribe to leap second notifications
USNO leap second data