[9fans] Re: Some plan9 y2k problems

[9fans] Re: Some plan9 y2k problems

[presotto]

Actually, depending on where you looked, the previous
code did have the algorithm right in dysize, i.e., leap
year every fourth year except every 100th year except every
400th year.  However by subtracting 1900 from the date,
calls to dysize treated the year 2000 as the year 100 and
therefore a multiple of 100 and not 400 and therefore not
a leap year.

As someone pointed out earlier, this should have been in
a library.  In some places we were saved by stupidity and
in some cursed by it.

[9fans] Re: Some plan9 y2k problems

[Russ]

  Unless someone changes time's type to "unsigned long" or "long long"
  before 2038...

I'm guessing that by 2038, time()'s type will be at least 64 bits.
I think we can scrounge up a factor of two in the next 40 years.
Just a hunch.

  It's not a bug, it's a feature!  Because of the year%400 rule, the year
  2000 *is* a leap year.  Therefore, between March 1, 1900 and Feb. 28,
  2100, the year%4 rule alone is valid.  UNIX's time span is well within
  this range.

No doubt this will go down in history as one
of the earliest justifications of the infamous y21c bug.
In 100 years, we will look back in disgust at the "foolish
Unix programmers" who thought that their code would certainly
be retired in the next 100 years.  And why stop there?  At this
rate we should all be preparing for the y10k bug, which certainly
will be much more disruptive than whatever happens in 11½ months.

Russ

[9fans] Re: Some plan9 y2k problems

[amos]

(I posted this on the plan9 newsgroup, but it isn't gated back to the
9fans list.  Apologies for those who see this twice).

presotto@plan9.BEll-labs.COM writes:

>In case anyone cares...

>They all involve screw ups in figuring out leap years.
>The ctime.c one is stupidly calls dysize with the year
>minus 1900 instead of the year.

It's not a bug, it's a feature!  Because of the year%400 rule, the year
2000 *is* a leap year.  Therefore, between March 1, 1900 and Feb. 28,
2100, the year%4 rule alone is valid.  UNIX's time span is well within
this range.

Unless someone changes time's type to "unsigned long" or "long long"
before 2038, there's no need to bother the system with code that will
only be executed once in 100 years, and even then come up with the same
result as existing code!

--
	Amos Shapir
Paper: nSOF Parallel Software, Ltd.
       Givat-Hashlosha 48800, Israel
Tel: +972 3 9388551   Fax: +972 3 9388552        GEO: 34 55 15 E / 32 05 52 N