As of 2002, the average Unix used a signed 32-bit integer to represent time as a count of seconds since 1970-01-01 00:00:00Z. The limits of that representation are 1901-12-13 20:45:52Z and 2038-01-19 03:14:07Z. Some platforms instead used an unsigned 32-bit integer (time starts in 1970) while others already used 64-bit integers.
XTide originally limited itself to the range 1970 to 2037. This provided portability and reliable results regardless of the time_t representation and allowed Interval (the difference between two timestamps) to be represented using a signed 32-bit integer. However, an increasing number of requests for historical "past predictions" combined with slow progress in migrating the average Unix platform to a time representation capable of surviving year 2038 finally motivated the incorporation of a workaround.
As of 2013, signed 64-bit time_t is provided by 64-bit Linux and unsigned time_t has fallen by the wayside. The workaround remains useful on 32-bit Linux, DOS, and Windows. Windows actually uses a signed 64-bit time_t, but the Run-Time Library barfs on dates before 1970 anyway. Go figure.
If XTide is compiled with the workaround, time_t is unconditionally defined as a signed 64-bit integer and the platform's time functions are bypassed. Years from 1 to 4000 are allowed. However, time zones and daylight savings time are sacrificed. Everything becomes UTC. *
The workaround can be enabled at configure
time using configure --enable-time-workaround
.
The range of years that is selectable in timestamp dialogs is
automatically expanded to 1700 to 2100 when the time workaround is
enabled. If a different range is required, the definitions of
Global::dialogFirstYear
and
Global::dialogLastYear
in Global.cc
must be
changed manually.
In order to obtain predictions for past and future years, it is also necessary to use a harmonics file that supports those years. The new harmonics file harmonics-dwf, rev. 2004-10-05 or later, supports the years 1700 to 2100. If you need to extend the range of years further, use the following procedure.
If you are using .txt and .xml files, you can extend the range of years as follows.
Please be aware that extrapolating predictions over large spans of time may give extremely inaccurate results. Don't even go there until you read this FAQ about it.
* The time scale used by the time workaround is not strictly speaking UTC since it does not implement leap seconds, but neither does the standard library. See Limitation #5.