From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <0d4dc20def50b211736d23c259e2bcf1@plan9.bell-labs.com> From: David Presotto To: 9fans@cse.psu.edu Subject: Re: [9fans] Fix to tm2sec(). In-Reply-To: <20030120065137.JFNO13460.mta3-rme.xtra.co.nz@[210.54.70.164]> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Mon, 20 Jan 2003 08:55:23 -0500 Topicbox-Message-UUID: 4435f8f0-eacb-11e9-9e20-41e7f4b1d025 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.