Date: Fri, 26 Oct 2001 18:33:49 -0700 From: Mike Smith <msmith@freebsd.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. Message-ID: <200110270133.f9R1Xnv06295@mass.dis.org> In-Reply-To: Message from Matthew Dillon <dillon@apollo.backplane.com> of "Fri, 26 Oct 2001 18:02:28 PDT." <200110270102.f9R12SO42251@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> :These programs should *not* be trying to use these functions. These functions > :are meant for manipulating time_t, which is a representation of "now". > > Who says? This is the definition of time_t. > Programs have used these functions to manipulate the concept > of time ever since the functions first came into being. And in many cases, that's perfectly appropriate, and time_t is more than adequate. However the examples you're citing as justification for this change are applications where time_t and friends just aren't appropriate. > Are you > suggesting that every single person who writes a program that manipulates > time that may not be 'now' must go and write his own library to support > that function? No. There are many time manipulation toolsets around customised for timescales other than reasonable values for "now". Pick one that suits your application and use it. Just don't go screwing up the time_t model to suit your own needs. > Your position makes no sense, Mike. We have to deal with programs that > are already written as well as developers expectations. Your expectations > seem far out in left field to me. time_t is a representation of time, > not a representation of time 'now'. That's just not correct. The concept of seconds post epoch is very definitely intended as a mechanism for representing a reasonable value of "now". If you're going to go and implement an incompatible mechanism for keeping track of time, at least have the good grace and civility to do so without ruining what is already a perfectly adequate means of representing the current system time. If you do a good enough job, it will probably become the new default, and over the next twenty years or so everyone will migrate to it. In the meantime, please do us all the favour of *not* screwing up the current way things are done. time_t will continue to be perfectly adequate for what it was designed for for another thirty years; imposing the sorts of changes you're talking about at this point in time just doesn't make any sort of good sense. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200110270133.f9R1Xnv06295>