Guardian Procedure Calls Reference Manual (G06.25+)

Guardian Procedure Calls (C)
Guardian Procedure Calls Reference Manual—522629-013
3-149
CONVERTTIMESTAMP Procedure
•
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
SETSYSTEMCLOCK.
For a more complete description of 48-bit and 64-bit timestamps, refer to the
TIMESTAMP or JULIANTIMESTAMP procedure.
•
Prior to 1987, DST in the United States started on the last Sunday in April; starting
with 1987, DST begins on the first Sunday in April. Timestamps occurring prior to
1987 are correctly converted in accordance with the previous standard.
•
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 should go back at least several years, to handle such things as
timestamps for files that have been created in the past. You should also provide
the most accurate DST transition information available for several years into the
future. DST transition information should go at least one year farther back and one
year farther in the future than you expect to encounter timestamps.