Quoted text is from <C093F2B9DDFD544283D02A8BB12588436B32BF@pai820excuag
02.ags.agere.com>, by Hurd, Richard A (Rich) <[EMAIL PROTECTED]>
>I have an app that accepts dates as MMCCYYDD. (I don't know why.)
>However, if you passed it a month of '20' it would be
>rather put out.
Dates are a sore point for EDI translation software. We have to be
prepared to translate between any of the allowed EDIFACT formats and, at
the very least, MMDDYY DDMMYY MMDDCCYY DDMMCCYY DD/MM/YY DD/MM/CCYY
CCYY/MM/DD and many more. The separator can be / - . or space. Full text
variants for Day of Week and Month are required. Individual sub-fields
can be variable or fixed length using either blank or zero for left
padding. Most of these requirements can be handled by a PERMUTE script
verb which can move around selected characters between a source and
target field using a mask.
The fun starts when you have to convert between conventional YYMMDD
content dates and Week Number (ISO or proprietary), first working day of
week, first working day of month, a date (however expressed) which is a
number of *working* days offset from a given date (however expressed),
resolve to the nearest working Monday or Thursday, etc. etc.
The algorithms are the stuff of nightmares. In some cases you end up
with external lookup tables which have to be refreshed 'manually' every
year or two, plus useful lists of the public holidays in most major
industrialised countries! The use of external tables is a cop-out, but
things like the algorithmic calculation of Easter (The first Sunday
after the first full moon after the Vernal Equinox) can be very tedious.
Regards
Chris
--
Chris Johnson +44 (0)20 8501 1490 (home)
EDIMatrix Ltd +44 (0)20 8559 2454 (work)
+44 (0)20 8559 2497 (fax)
http://www.edimatrix.co.uk
=======================================================================
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
