* [9fans] Fix to tm2sec().
@ 2003-01-18 23:03 Dan Cross
2003-01-18 23:07 ` David Presotto
2003-01-19 0:10 ` Russ Cox
0 siblings, 2 replies; 11+ messages in thread
From: Dan Cross @ 2003-01-18 23:03 UTC (permalink / raw)
To: 9fans
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%
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] Fix to tm2sec().
@ 2003-01-19 20:43 Andrew Simmons
2003-01-19 21:33 ` Dan Cross
0 siblings, 1 reply; 11+ messages in thread
From: Andrew Simmons @ 2003-01-19 20:43 UTC (permalink / raw)
To: 9fans
> 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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] Fix to tm2sec().
2003-01-19 20:43 Andrew Simmons
@ 2003-01-19 21:33 ` Dan Cross
2003-01-19 21:48 ` rob pike, esq.
0 siblings, 1 reply; 11+ messages in thread
From: Dan Cross @ 2003-01-19 21:33 UTC (permalink / raw)
To: 9fans
> 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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] Fix to tm2sec().
@ 2003-01-20 6:49 Andrew Simmons
2003-01-20 7:21 ` Russ Cox
2003-01-20 13:55 ` David Presotto
0 siblings, 2 replies; 11+ messages in thread
From: Andrew Simmons @ 2003-01-20 6:49 UTC (permalink / raw)
To: 9fans
>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?
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] Fix to tm2sec().
2003-01-20 6:49 Andrew Simmons
@ 2003-01-20 7:21 ` Russ Cox
2003-01-20 13:55 ` David Presotto
1 sibling, 0 replies; 11+ messages in thread
From: Russ Cox @ 2003-01-20 7:21 UTC (permalink / raw)
To: 9fans
we could always change to 100s of nanoseconds since january 1, 1600.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] Fix to tm2sec().
2003-01-20 6:49 Andrew Simmons
2003-01-20 7:21 ` Russ Cox
@ 2003-01-20 13:55 ` David Presotto
1 sibling, 0 replies; 11+ messages in thread
From: David Presotto @ 2003-01-20 13:55 UTC (permalink / raw)
To: 9fans
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2003-01-20 13:55 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-01-18 23:03 [9fans] Fix to tm2sec() Dan Cross
2003-01-18 23:07 ` David Presotto
2003-01-18 23:12 ` Dan Cross
2003-01-19 0:10 ` Russ Cox
2003-01-19 0:20 ` Dan Cross
2003-01-19 20:43 Andrew Simmons
2003-01-19 21:33 ` Dan Cross
2003-01-19 21:48 ` rob pike, esq.
2003-01-20 6:49 Andrew Simmons
2003-01-20 7:21 ` Russ Cox
2003-01-20 13:55 ` David Presotto
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).