Re: date formats
- From: jcewing@xxxxxxx (Joel C. Ewing)
- Date: 15 Aug 2010 18:02:06 -0700
On 08/15/2010 03:07 PM, Paul Gilmartin wrote:
On Sun, 15 Aug 2010 08:23:18 -0400, Shmuel Metz (Seymour J.) wrote:
In <LISTSERV%201008131709378676.06B9@xxxxxxxxxxx>, on 08/13/2010Well, yes. The entire 21st century is intrinsically incompatible
at 05:09 PM, Paul Gilmartin said:
I'll agree enthusiastically except where the change could be made in
a compatible manner, altering no sizes, displacements, nor content of
existing data bases. One example might be that where Dec. 31, 1999
is represented as x'99365', Jan. 1, 2000 could (have) been
represented as x'A0001'
That would not have been compatible.
with software incapable of formatting dates past 1999. I merely
suggested that bit patterns previously deemed invalid could be
used (as a stopgap, I failed to say) to encode a further range of
dates until necessary changes in data formats can be made.
-- gil
The point of Shmuel's comment, of course, is that the one most common,
unavoidable-in-MVS place where dates of the form yyddd were in
wide-scale use was in SMF accounting records. The format there is
packed-decimal, so hex digits are out. The old format was actually
+00yyddd, where the 00 was reserved, so the one and only way to preserve
the packed decimal representation and also preserve the existing
relationship that the representation for the next year is current year +
1 (in base 10) was to go with 2000-01-01 == 0100001, which is what IBM
did. For those who were already converting SMF dates into a four-digit
year via 00yyddd + 1900000, this extension was so compatible that it
wasn't even necessary to make any code changes for Y2K!
Granted, if you had existing databases or files with 3-byte-decimal or
5-character YYDDD dates, you had a much more serious problem. Any way
you went, using-unused bits, expanding the field, at some instant the
field definition would change and all code touching that field had to be
revised accordingly. Except for separate interpretation rules for older
archived data, it always made sense to us that if you had to change a
field and all related programs it was best to stick with simpler
representations that avoided future headaches. If a larger field was
unacceptable, a 3-byte integer Lilian date is much simpler to work with
in the long run than having different bit-twiddling rules for different
digits of the year.
The original question raised of what date formats should be supported by
a conversion routine has a different answer if the object is to support
a single installation rather than for a general purpose vendor utility.
It makes sense that local installation standards should try to minimize
the number of different date representations used locally to minimize
confusion and needless conversions.
--
Joel C. Ewing, Fort Smith, AR jcewing@xxxxxxx
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@xxxxxxxxxxx with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
.
- References:
- Re: date formats
- From: Paul Gilmartin
- Re: date formats
- Prev by Date: Re: Anyone Using z10 Large Pages in anger?
- Next by Date: Re: Anyone Using z10 Large Pages in anger
- Previous by thread: Re: date formats
- Next by thread: Re: date formats
- Index(es):
Relevant Pages
|
