Return-Path: linux-nfs-owner@vger.kernel.org Received: from terminus.zytor.com ([198.137.202.10]:53242 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754969AbaFBRP4 (ORCPT ); Mon, 2 Jun 2014 13:15:56 -0400 Message-ID: <538CB085.5000502@zytor.com> Date: Mon, 02 Jun 2014 10:12:37 -0700 From: "H. Peter Anvin" MIME-Version: 1.0 To: "Theodore Ts'o" , Chuck Lever , Arnd Bergmann , Nicolas Pitre , Dave Chinner , LKML Kernel , linux-arch@vger.kernel.org, joseph@codesourcery.com, john.stultz@linaro.org, Christoph Hellwig , tglx@linutronix.de, geert@linux-m68k.org, lftan@altera.com, linux-fsdevel , xfs@oss.sgi.com, Linux NFS Mailing List Subject: Re: [RFC 11/32] xfs: convert to struct inode_time References: <1401480116-1973111-1-git-send-email-arnd@arndb.de> <8618458.1EVJCoVbkH@wuerfel> <4178301.j9kWdGCRLC@wuerfel> <6868F108-F0B2-423F-AE31-90DF86A5B7DD@oracle.com> <20140602153124.GH30598@thunk.org> In-Reply-To: <20140602153124.GH30598@thunk.org> Content-Type: text/plain; charset=UTF-8 Sender: linux-nfs-owner@vger.kernel.org List-ID: On 06/02/2014 08:31 AM, Theodore Ts'o wrote: > > I wonder if it would make sense to try to promulgate via the Austin > group, and possibly the C standards committee the concept of a bit > pattern (that might commonly be INT_MAX or UINT_MAX) that means "time > unknown", or "time indefinite" or "we couldn't encode the time". > (time_t)-1 already has this meaning for some calls (e.g. time(2)). However, this also means Wed Dec 31 23:59:59 UTC 1969, and unfortunately something similar applies to all possible bit patterns, certainly within the range of an int. > We would then teach gmtime(3) and asctime(3) to print some appropriate > message, and we could teach programs like find (with the -mtime) > option, make, tmpwatch, et. al., that they can't make any presumption > about the comparibility of any timestamp which has a value of > TIME_UNDEFINIED. > > It would be problematic for time(2) or gettimeofday(2) to return > TIME_UNDEFINED, since there are programs that care about time ticking > forward, but I could imagine a new interface which would be permitted > to return a flag indicating that we don't know the current time > (because the CMOS battery had run down, etc.) so instead we're going > to be counting the number of seconds since the system was booted. This assumes that we actually know that that is the case, which may be an aggressive assumption. -hpa