Guardian Procedure Calls Reference Manual

• LCT timestamps
LCT timestamps should be used with caution because of the negative adjustment that DST
systems dictate. Timestamp base conversion (for example, LCT) is provided by the operating
system.
• A 64-bit Julian timestamp is based on the Julian date. It is a quantity equal to the number of
microseconds since January 1, 4713 B.C., 12:00 (noon) Greenwich mean time (Julian proleptic
calendar). This timestamp can represent either Greenwich mean time, local standard time, or
local civil time. There is no way to examine a Julian timestamp and determine which of the
three times it represents.
Procedures that work with the 64-bit Julian timestamp are COMPUTETIMESTAMP,
CONVERTTIMESTAMP, INTERPRETTIMESTAMP, JULIANTIMESTAMP, and
SYSTEMCLOCK_SET_/SETSYSTEMCLOCK.
For a more complete description of 48-bit and 64-bit timestamps, see the TIMESTAMP Procedure
(page 1424) or the JULIANTIMESTAMP Procedure (page 747).
• Timestamps occurring before 1987 and 2007 are correctly converted in accordance with the
previous standards.
• Setting up a DST table
If your system is configured to use a DST table, add entries carefully to the DST table to avoid
problems in the conversion of timestamps by CONVERTTIMESTAMP.
These problems can arise when your system uses a DST table:
◦ Inaccurate conversions because of wrong information in the DST table
◦ Programs abending or taking other extreme actions in response to errors reported by
CONVERTTIMESTAMP
It is important to set up the DST table to prevent CONVERTTIMESTAMP reporting error 1 (DST
range error) or error 2 (DST table not loaded) because many programs take extreme actions
in response to these errors. For example, BIND is known to abend in response to error 1 or
error 2, and SQLCOMP fails in response to BIND abending. BACKUP and RESTORE have
also been known to fail in response to error 1 or error 2.
To allow CONVERTTIMESTAMP to perform accurate conversions from GMT to LCT, it is
important to provide accurate information for DST transitions for all timestamps that
CONVERTTIMESTAMP is likely to encounter. The accurate DST table entries must go back at
least several years, to handle such things as timestamps for files that have been created in the
past. You must also provide the most accurate DST transition information available for several
years into the future. DST transition information must go at least one year farther back and
one year farther in the future than you expect to encounter timestamps.
It is vital to add at least one period of nonzero DST offset to the DST table, to avoid
CONVERTTIMESTAMP reporting error 2 (DST table not loaded).
In addition to the accurate table entries recommended above, it is good practice to add
fictitious entries to the DST table, to avoid CONVERTTIMESTAMP reporting error 1 (DST range
error) when it converts times earlier than expected or later than expected. It is good practice
to add a fictitious entry for a time far in the past and a fictitious or speculative entry for a time
far in the future. For example, you might add DST table entries for the year 1000 and for the
year 3999.
To add entries to the DST table, use these procedures:
ADDDSTTRANSITION procedure or the ADDDSTTRANSITION TACL
command
G04.00 and earlier G-series RVUs
ADDDSTTRANSITION procedure, ADDDSTTRANSITION TACL command,
or the DST_TRANSITION_ADD_ procedure
G05.00 and later G-series RVUs
CONVERTTIMESTAMP Procedure 223