Re: [MacPerl] [ALBOT] Mac Y2K Oops?

[Richard Gordon <gordon@mindspring.com>]

On 2/6/99 at 23:07, rjk@linguist.dartmouth.edu (Ronald J. Kimball) wrote:

> I don't see how this would be an issue with time or localtime.  time()
> returns seconds since the epoch; localtime() converts seconds since the
> epoch into a date.  There's no obvious ambiguity there.
>
Perhaps not. I've yet to attempt to do any date math with MacPerl and was just
throwing out the first functions that came to mind. So how do you handle
String->Date conversions in MacPerl (or Perl for that matter), Date::Manip or
Date::Calc? Are these dependent on the host OS and subject to any problems that
it may have?

> > My concluding comment is that I would imagine that Apple could patch the
> > function pretty easily, but I'm having a little trouble understanding why
> > this apparently hasn't been addressed by Apple thus far. Any thoughts?
> 
> How should Apple "address" this?  How would you have them patch the
> function?
> 
> If you write out ambiguous dates, then you have to deal with that ambiguity
> when you read the dates back in.  Apple's way of dealing with the
> ambiguity, going by your description, seems to be as good as any, and
> better than some.
> 
> The only real fix is to the data and the output routines.

A fix would have to be arbitrary, but no more so than the current function is.
Maybe change the cutoff from 90 to 60? Maybe build a more sophisticated case
statement?

It's fine to say that you shouldn't create problems for yourself by writing
ambiguous dates, but this overlooks the fact that most people have to contend
with data that did not originate with them and could be in any number of bizarre
formats. Altho you could routinely scrub all incoming files to clarify dates,
this would be at least as arbitrary as simply changing the rules that
StringToDate uses and cause a lot of maintenance problems to boot. Payment
histories, billing histories, amortization schedules, and all kinds of other
stuff that will be with us for a decade to come are embedded with 2 digit years
and it begs the question to say that it should not have been done that way.
Apple has a minor leg up in being able to say that it has always anticipated
y2k, but this flaw needs to be resolved in order for that to be literally true.

Richard Gordon
Gordon Consulting & Design
Voice: 770-565-8267  Fax: 770-971-6887



***** Want to unsubscribe from this list?
***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch