|
PureBytes Links
Trading Reference Links
|
Dark Hacker wrote:
> You are describing a data conversion fix. If the Omega
> Server accepts data that is in 19XX or 20XX format then
> this heuristic might be an acceptable temporary fix (good
> for another 20 years or so).
Current versions of TradeStation will be irrelevant twenty years from now.
I am not arguing trading software should not be able to accept dates with
four-digit years. It should be able to. I only am pointing out that the
world is not going to come to an end because the Gregorian calender year
increments from 1999 to 2000.
Trading software should be able to use either two- or four-digit year dates.
Two-digit year compatibility is important, because two-digit years have
been, and will continue to be, widely used. Where two-digit years are used,
there is no alternative to making a reasonable assumption about the missing
digits. Four-digit year capability is important to those analyzing
exceptionally long trade histories, which TradeStation is not very well
suited for anyway.
However, once again, this is a different issue than we have been discussing.
We have been discussing a supposed year 2000 crisis, not desirable software
capabilities.
> Just convert the XX into a full date based on its apparent
> age before it gets to the Omega Server.
>
> But this assumes that both the server and Tradestation can
> accept a 4 character date format. If it can't, you're hosed
> and any date comparison routines in the software must be
> changed (example: 01 > 97 == FALSE).
That isn't true. Only an amateur programmer would do Gregorian calendar
date comparisons. The Omega Server, the TradeStation and SuperCharts
charting programs, and properly written Easy Language programs all call a
common Gregorian to pseudo Julian conversion function in a DLL supplied with
Omega products. If that routine doesn't already assume low value years are
in the next century, a very simple patch could cause it to make that
assumption. A simple fix therefore, if it is even necessary, would fix date
comparisons throughout the system.
Where traders without much programming experience have made Gregorian date
comparisons in Easy Language programs, they may need to modify them to use
the Easy Language DateToJulian function as they should have in the first
place. That won't be a year 2000 crisis. The changes will be simple and a
good learning experience.
> I'm sure that companies dealing with insurance policies,
> annuities and mortgage back securities have already dealt
> with the Y2K problem or some components of their software
> would fail today.
Of course, they have. Most professional software written the last 15 years
use Julian calendar dates for internal days-between-date calculations. The
serious year 2000 problems mostly are in very old programs. Even in those
old programs, serious problems are mostly limited to two aspects. One is
with days-between-dates calculations. The other is with the need to either
expand database date fields to allow for four-digit dates or to change date
fields from a string data type to a long numeric data type to allow Julian
date storage.
In addition to those two potentially serious problems, there are the trivial
problems focused on by most people on this list. The trivial problems have
to do merely with date input and output. There are two possible solutions
to the trivial problems. One is to make a reasonable assumption about the
century where two-digit years are used. The other is to provide for four-
digit years.
Omega software only has the trivial input/output problems, because the Omega
Server database already saves pseudo Julian dates and Omega software doesn't
do days-between-dates calculations. Most of the year 2000 Omega software
concerns expressed on this list are ridiculous.
-Bob Brickey
Scientific Approaches
sci@xxxxxxxxxx
|