Re: [9fans] Fix to tm2sec().

Re: [9fans] Fix to tm2sec().

[Andrew Simmons]

> I strenuously object to changing the meaning of tm->year.

I'd second the strenuous objection. The 1900 base is not just a Unix 
thing - as far as I know it's part of ANSI C. It certainly works the 
same way in every C implementation I've used, on Mac, Windows, & VMS. 
Even though struct Tm isn't quite the same as struct tm, I'd hate to 
see them made even more subtly incompatible. As Doug Gwyn said the 
other day, standards have a purpose. 

I'd be fine with the change to make Mr Presotto's birthday day 1 (or 
should it be day 0?) though. I believe the standard is silent on this 
point.

Re: [9fans] Fix to tm2sec().

[Dan Cross]

> I'd second the strenuous objection. The 1900 base is not just a Unix 
> thing - as far as I know it's part of ANSI C. It certainly works the 
> same way in every C implementation I've used, on Mac, Windows, & VMS. 
> Even though struct Tm isn't quite the same as struct tm, I'd hate to 
> see them made even more subtly incompatible. As Doug Gwyn said the 
> other day, standards have a purpose. 

This reason I can't agree with.  Fixing all the problems that might
crop up is a lot of work, but if I want POSIX, I know where to get
it.  I don't really want POSIX, which is why I run Plan 9.

> I'd be fine with the change to make Mr Presotto's birthday day 1 (or 
> should it be day 0?) though. I believe the standard is silent on this 
> point.

Actually, it's not, but if Dave's birthday falls on a particularly
auspicious day, it could be all right.  :-)

	- Dan C.

Re: [9fans] Fix to tm2sec().

[rob pike, esq.]

> Actually, it's not, but if Dave's birthday falls on a particularly
> auspicious day, it could be all right.  :-)

I think the problem would be that we'd need 64-bit ints to represent the
modern era.

-rob

Re: [9fans] Fix to tm2sec().

[David Presotto]

We've got a number of time bases, all somehow unalike.  System time is kept
as a signed 64 bit number representing nanoseconds since (or, if negative,
before) the start of 1970.  It represents a 584 year time span and runs out
in 2262.

Most programs just care about seconds though.  That time base also starts
at the beginning of 1970 and runs out in 2038 just like the Unix one.  I
expect that we'll turn it into a ulong before we get there it Plan 9
is still around.

I specificly didn't use the NTP's approx 232 ns units because they ran
out as early as Unix's (and our) seconds.  They picked those units
to make the conversion twixt them and seconds easy.  It's just a 32
bit shift.  While I appreciate that, I preferred a unit that would
be a little more meaningful given the accuracy of GPS and also
one that would be easier to explain than a 1/(2^32).  I felt
justified in picking my own units partially because they are
actually units other people use (unlike the NTP one) and
because we didn't have system calls in common with Unix
where the difference would be confusing.

Finally, we come to the Tm structure that gives time broken down into more
conventional units so that we can print them.  There the oddest part
is the representation of year as year - 1900.  It is true that I
can't ever remember the 1900 offset.  However, since we are using
exactly the same preresentation as Unix, same library names that
return it (gmtime, localtime), I don't think the arbitrary change
is worth the eventual pain in converting programs.  I realize that
the ape stuff (and now gcc) will be used for most Unix programs on
Plan 9, but we still pick up little bits often enough that arbitrary
changes are a pain.  We do got the other way too, you know.  I'm
constantly tripping over stuff now that I'm converting Plan 9
code to Windows, as often because of arbitrary changes on the Windows
side.  I am sorry that I just changed the units of sleep() without
changing the name of the call, for example.  That trips me up
every time.

Re: [9fans] Fix to tm2sec().

[Russ Cox]

we could always change to 100s of nanoseconds since january 1, 1600.

Re: [9fans] Fix to tm2sec().

[Andrew Simmons]

>This reason I can't agree with.  Fixing all the problems that might
>crop up is a lot of work, but if I want POSIX, I know where to get
>it.  I don't really want POSIX, which is why I run Plan 9.

Actually, I was intending to refer to ANSI C, rather than POSIX - I believe
they are different, although overlapping, and I was once told that it's
POSIX that specifies a starting date and interval for time_t values, whereas
ANSI C leaves both undefined.

But even if the standards argument doesn't sway you, surely you could spare
a thought for those of us (oh well, all right, just me) who are so old and
senile and stupid that even 128 bit integers would not suffice to represent
our age, and are consequently unable to come to terms with a zero-based
number system?

Re: [9fans] Fix to tm2sec().

[Dan Cross]

> I strenuously object to changing the meaning of tm->year.
> Maybe I'm a curmudgeon.  It would probably be better in
> the long run but in the short run I really don't want to 
> find all the programs that it would break.

How curmudgeony.  Okay, fine; we leave tm->year as is for now.

> I don't object to your yday patch.

Cool.

	- Dan C.

Re: [9fans] Fix to tm2sec().

[Russ Cox]

I strenuously object to changing the meaning of tm->year.
Maybe I'm a curmudgeon.  It would probably be better in
the long run but in the short run I really don't want to 
find all the programs that it would break.

I don't object to your yday patch.

Re: [9fans] Fix to tm2sec().

[Dan Cross]

> It's very goofy but I don't feel like changing it.

I don't feel like changing it tonight but maybe in a week or two I
would feel differently.  Does anyone strenuously object?

	- Dan C.

Re: [9fans] Fix to tm2sec().

[David Presotto]

It's very goofy but I don't feel like changing it.

[9fans] Fix to tm2sec().

[Dan Cross]

I fixed a bug in tm2sec() where it didn't take into account tm->yday.
Now, if tm->yday is nonzero, it uses that instead of accumulating
seconds based on month and day in month.  A patch in diff -e format
follows.

btw- The handling of tm->year seems suboptimal to me; shouldn't this be
the 4 digit year, instead of the current year - 1900?  I realize that
on Unix, (struct tm *)->tm_year is years since 1900, but this isn't
Unix, and it just strikes me as goofy.

	- Dan C.

term% diff -e /n/sources/plan9/sys/src/libc/9sys/tm2sec.c tm2sec.c
76,79c
		/*
		 * secs in last month
		 */
		secs += (tm->mday-1) * SEC2DAY;
	}
.
69,74c
	if (tm->yday != 0)
		secs += (tm->yday - 1) * SEC2DAY;
	else {
		/*
		 *  seconds per month
		 */
		d2m = yrsize(year);
		for(i = 0; i < tm->mon; i++)
			secs += d2m[i+1] * SEC2DAY;
.
term% pwd
/sys/src/libc/9sys
term%