On 21 Sep 2013 13:54, Jerry C. Adams wrote:
<<SNIP>> what is the maximum (latest, whatever) time/date that
currently can be recognizing on the System i?
9999-12-31-23.59.59.999999 is the latest for any interface of which I
am aware.
I recently came across this video
(http://www.numberphile.com/videos/unix_time.html) that is about
(obviously) Unix time. The year (2038) mentioned in the video
sounded vaguely familiar.
So, when does Time stop (on the System i)? Or loop (time travel?)?
FWiW: Searching the InfoCenter on the token 1928 is helpful to find
information about the OS time-stamp because that is the year for its
beginning-of-time.
FWiW: The year 2039 [very close to 2038] may be familiar to many on
the IBM i due to the default 100-year-window interpretation of two-digit
year formats; i.e. dates across the years 1940-2039 are understood and
representable in a two-digit year format, with either an inference or
implication for the missing [effective century] digits, as being either
'19' or '20'.
The OS date\time is described indirectly, in _older release_ help
text of the QDATE system value, as:
"System date. The format of the system date is specified in the system
value QDATFMT. The system supports dates that range from August 24,
1928 to July 6, 2053. ..."
The _current release_ help text for QYEAR changed to describe the OS
date\time support [what previously was documented under QDATE] in years:
"the range of dates supported by the system (1928 to 2053)".
Apparently, as limited by the implementation for the QCENTURY with the
only two possible values documented in the help text as being _zero_ for
"(the years from 1928 to 1999)" and _one_ for "(the years from 2000 to
2053)" with the explicit *Note* that "1900 to 1927 and 2054 to 2099 are
not supported years for system time. Applications can, however, support
year date ranges from 0001 to 9999." Apparently this is because "When
QYEAR or the year in QDATE is changed:
* QCENTURY is set to 0 if QYEAR is 54 to 99
* QCENTURY is set to 1 if QYEAR is 00 to 27"
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/nls/rbagsqcenturyuse.htm
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/nls/rbagsqyearuse.htm
But then to confuse the issue, seemingly contradictory to the
aforementioned capabilities of the "dates supported by the system"...
According to the Set System Time (QWCSETTM) API, the "supported date
range is from August 23, 1928, 12:03:06.314752 to May 10, 2071,
11:56:53.685240"
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/apis/qwcsettm.htm
And to thoroughly confound someone investigating an answer to what is
really supported for the OS date\time... According to the documentation
for using iNav as the means to set the System Date [which presumably
uses the above API], the "system supports dates that range from 24
August 1928 to 7 June 2062. If the Year (QYEAR) system value changes to
a different century, the system automatically updates the Century
(QCENTURY) system value." Yet if we are to believe the previously noted
QCENTURY limits, years 2054-2062 are *not supported* and ¿possibly even
can not be set?!?
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/rzakz/rzakzqdate.htm
Despite the confusing references noted above, I recall the value of
the /system date/ as implemented with the *DTS has the largest of those
noted-as possible limits for the /system date/ support. I can not find
specific documentation for the *DTS System TimeStamp 8-byte values, but
the largest 2071 timestamp noted, is its upper limit. Converting the
largest 8-byte *DTS value to a date\time with the Convert Date and Time
Format (QWCCVTDT) API confirms that effect.
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/apis/qwccvtdt.htm
For example the Convert Date (CVTDAT) suggests that its "valid dates
are in the range of August 24, 1928, to May 9, 2071" which is mostly
consistent with the limits for the /System Timestamp/ value. Presumably
the day 10-May-2071 is not supported, because that allows only for a
partial day. Again, the system value QDATE and QYEAR [year] limitation,
seems only due to a limit for the QCENTURY support.
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/cl/cvtdat.htm
Similarly, the CL Command object type *CMD date data type support for
parameters per the special value *DATE has support for "dates with
2–digit years to be in the range of January 1, 1940, to December 31,
2039. Dates with 4–digit years must be in the range of August 24, 1928,
to May 9, 2071" so again that seems consistent with the use of the *DTS
and its effective upper limit [spanning a full day].
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/rbam6/prtyp.htm
However, long before there is likely to be any issue for the OS
itself [almost exclusively the ability to represent /today/ plus likely
no more than up to a year into the future, typically for scheduling], I
suspect the question is possibly more applicable and important to the
applications, for what they support. The OS does provide access to the
"Unix" time APIs, so any applications using those would seem to be more
likely to be in trouble. While the OS mostly needs only to represent
the /current/ dates [*nix or IBM i], the applications are more likely to
need to express dates far into the future, thus pressing much closer to
that 2038 boundary. Unless a component of the OS uses the *nix time
[e.g. those implemented using applications in PASE compiled by AIX],
they are unlikely to be impacted by those *nix time limitations.
midrange.com
