Re: Year 2000

Subject: Re: Year 2000
From: "Doug, Data Librarian at Ext 4225" <engstromdd -at- PHIBRED -dot- COM>
Date: Fri, 9 Dec 1994 15:03:31 -0600

glen accardo opines...

**********************
Any software worthy of using stores Julian dates: usually a long integer
representing the number of days/seconds/whatever-time-units from some
point to the date represented.....

[Some good stuff of the superiority of Julian dates for other reasons]

The real problem is WHAT you are sorting: you need to sort dates, not strings.
**********************

No argument from me there; it's just that for some reason, particularly in
the case of hand-coded COBOL apps on mainframes, it wasn't done that way in
many shops for many years. I suspect, but do not know, that it may have
been more difficult to maintain a reasonable integer-based standard before
database management systems and their DATETIMESTAMP formats. It's all
very well to choose a specific date in the past and count some unit from
that time to this, but if you don't have an enforceable standard that
tells you what the benchmark date is and what the unit is, things could
get ugly in a hurry. But as I said, this is conjecture.

Unfortunately, the most vulnerable applications are the very ones that keep
the wheels turning in many corporations. I don't have the experience to
pass judgement on the author's assertion that the problem is "widespread"
but I thought it was worth bringing up.

Skoal,

Doug "Women are designed for long,
ENGSTROMDD -at- phibred -dot- com miserable lives, whereas men are
designed for short, violent ones."
- Estelle Ramey


Previous by Author: Re: Year 2000
Next by Author: Re: Year 2000
Previous by Thread: Re: Year 2000
Next by Thread: Year 2000


What this post helpful? Share it with friends and colleagues:


Sponsored Ads