Date: 27 Oct 2001 01:46:29 +0200 From: Dag-Erling Smorgrav <des@ofug.org> To: Bakul Shah <bakul@bitblocks.com> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, Peter Wemm <peter@wemm.org>, arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. Message-ID: <xzpsnc6q816.fsf@flood.ping.uio.no> In-Reply-To: <200110262321.TAA14697@ajax.cnchost.com> References: <200110262321.TAA14697@ajax.cnchost.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Bakul Shah <bakul@bitblocks.com> writes: > I don't want to have to change a bunch of exiting programs > just because someone decided change time_t to a 64 bit > quantity. That is why I would really prefer a new typename > for a 64 time type. No, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no and no. I'm almost insulted that you (and others) seem to be arguing from the premise that us effwit FreeBSD committers are too stupid to realize we need to provide an upgrade path. Give us some effing credit. > For file timestamps nstime64_t seems adequate to me for reasons > I gave before -- may be mtime/atime/utime type should not be > called time_t either. Obviously. After all, nobody uses time_t for anything else that file timestamps - at least nobody we care about (or will care about in 2038), so there's no need for ctime(), difftime(), gmtime(), localtime(), mktime(), time(), timelocal() or timegm() to continue working as before. > Also, this is problem is not peculiar to FreeBSD and I really > hope you (core) guys try to come to some consensus with other > OS groups. Since you're so stuck up about standardization, go see POSIX or SUSv2 or the Austin spec and show me a single reference to "nstime64_t" in any one of those documents. I will not discuss this any further. It's too much like teaching pigs to sing. DES -- Dag-Erling Smorgrav - des@ofug.org 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?xzpsnc6q816.fsf>