Hi,
I think that the only way to handle overloaded dates is to allow the
user to specify what happens for a variety of dates. What if the
date conversion was fed a rules file, where the first "matching" rule
is used. (Note, several assumptions buried in example, including
HP supported/documented date data types!)
Rule file notes:
# comments begin with "#".
# File format: input : output
# keywords...
# $FORMAT ## : ## ... specifies which documented format is being used for
# input, output. (yes, could be info given to the
# conversion program, but is data that is far better
# included *with* the rules!)
# VALID --> a date that is a legal date.
# INVALID --> a date that is not a legal date.
# DROP --> (modifier, only for output) delete the entry with the date,
# if possible. If not possible, treat as specified)
# RETAIN --> don't change
# @ --> matches any date
# "xxxx" --> ASCII text (e.g.: "EXPIRE" might be found in an X6 field)
# #nnnn --> Indicates numeric value (e.g.: #0) that might be found in
# an field value (e.g., #0 might be found in an I2 field)
# LOWEST --> lowest legal date
# HIGHEST --> highest legal date
# [date1, date2] --> matches all *legal* dates in range, including
two dates shown (closed list)
# (date1, date2) --> ... excluding two dates shown (open list)
# [date1, date2) --> ..., including date1, excluding date2
# (date1, date2] --> ..., excluding date1, including date2
# (ranges may use LOWEST/HIGHEST as constants)
Rule file #1: (all valid dates preserved, all invalid dates deleted
if possible otherwise converted to 1900-01-01)
also, site once had bad code that accepted 1990-02-29
as legal date...we want to change it to 1990-03-01)
$FORMAT HP3 : HP3 # YYMMDD : YYMMDD
1990-02-29 : 1990-03-01 # fix leap year problem we once had
VALID : RETAIN
INVALID : DROP 1900-01-01
Rule file #2: (using HP standard date format #93)
(rejects dates prior to 1990-01-01 and after 2009-12-31)
$FORMAT HP3 : HP93 # defines how NEVER and UNKNOWN are represented
# format 3 is X6 YYMMDD, format 93 is 16-byte HP format
1999-12-99 : NEVER
[1990-01-01, 2009-12-31] : RETAIN
"UNKNOW" : UNKNOWN # convert X6 text to proper value
"EXPIRE" : 1900-01-01
@ : INVALID
Rule file #3: (CALENDAR to X8:YYYYMMDD, illegals --> 0000-01-01)
$FORMAT HP4 : HP92 # yes, I'm making up the numbers, for now!
VALID : RETAIN
INVALID : 0000-01-01
Every rule file ends with an implicit:
VALID : RETAIN
INVALID : LOWEST
At startup, the rules file is parsed for dates that are illegal according
to the specified input/output formats. (E.g., if the output format
is in CALENDAR format, then the output date of 1800-01-01 is not legal,
and would imply an incorrect rules file.)
> Yes, overloading is horrible. But people do it all the time. We don't
Yep...that's why I'm pushing for some date standards that, like IEEE real
numbers, include "oddball" concepts like: UNKNOWN, EXPIRED, NEVER, and
INVALID as well as legal dates...standards that include CALENDAR, YYMMDD,
MMDDYY (in ASCII and binary), and others.
--
Stan Sieler [log in to unmask]
http://www.allegro.com/sieler.html
|
