Problems within epicsTime.cpp

["Denison, PN (Peter)" <peter.denison@diamond.ac.uk>]

In the process of working on the "timeGovernor"/"generalTime" code and
integrating it into base (yes I have been working on it, and sorry it's
gone a bit quiet for a while), I have discovered a rather interesting
anomaly to do with the way the EPICS epoch is defined. Fortunately, for
everyone else that is, it only affects the UK!

The existing code in the epicsTimeLoadTimeInit constructor
(src/libCom/osi/epicsTime.cpp) uses mktime() first on 1/1/1970 00:00:00,
and then on 1/1/1990 00:00:00 and calculates the difference. On
up-to-date Linux systems, it is this use of mktime() that causes the
problem.

If you have the system timezone set to UTC, GMT, GMT0BST, or even
GMT0BST,M3.5.0/1,M10.5.0/2 then all is well, and the unixEpoch time_t is
calculated as 0, and the offset to epicsEpoch calculated as 631152000.
The same is true on vxWorks, FreeBSD 4.11. On Linux (RH EL4, debian
etch) and OS.X 10.4, and if the timezone is set to "Europe/London", then
you get the incorrect figure of 631155600, one hour too large.

It turns out that between October 1968 and October 1971, the UK operated
on "British Standard Time" which was a constant GMT+1, for reasons
better known to the politicians of the time. Since I was only 2 at that
point, I shall refrain from commenting, perjoratively or otherwise!
However, since that time period encompasses the Unix Epoch, it causes us
a problem, if we use the _local_ representation of time to work out the
offset between the ansiEpoch and epicsEpoch.

Doing so is invalid anyway, since the ansiEpoch is defined as "UTC
seconds since 00:00:00 1/1/1970UTC", and presumably the EPICS Epoch is
defined similarly. I'm not entirely clear why we're going through the
whole rigmarole of calling mktime() twice, and calculating the
difference, rather than hard-coding the value of 631152000. It's not as
if the difference between the two epochs can vary. I had initially
thought that we could leave the existing code in place, and run
epicsEnvSet to set the timezone to UTC, and then revert it, then I
realised how unnecessary it is, since we are trying to get a constant
out.

Can I replace this code in epicsTimeLoadTimeInit with a constant?

-- 
Peter Denison, Senior Software Engineer, Diamond Light Source Ltd.
Tel: +44 1235 778511
(apologies in advance for the lines below. Some bits are a legal
requirement and I have no control over them)