From mboxrd@z Thu Jan 1 00:00:00 1970 From: "H. Peter Anvin" Subject: Re: [RFC 06/32] isofs: fix timestamps beyond 2027 Date: Sat, 31 May 2014 01:47:19 -0700 Message-ID: <53899717.1050109@zytor.com> References: <1401480116-1973111-1-git-send-email-arnd@arndb.de> <1401480116-1973111-7-git-send-email-arnd@arndb.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org To: Geert Uytterhoeven , Arnd Bergmann Cc: "linux-kernel@vger.kernel.org" , Linux-Arch , "Joseph S. Myers" , John Stultz , Christoph Hellwig , Thomas Gleixner , Ley Foon Tan , Linux FS Devel List-Id: linux-arch.vger.kernel.org On 05/31/2014 12:59 AM, Geert Uytterhoeven wrote: > On Fri, May 30, 2014 at 10:01 PM, Arnd Bergmann wrote: >> isofs uses a 'char' variable to load the number of years since >> 1900 for an inode timestamp. On architectures that use a signed >> char type by default, this results in an invalid date for >> anything beyond 2027. >> >> This adds a cast to 'u8' for the year number, which should extend >> the shelf life of the file system until 2155. > > Oops, the CD archive of my scanned Napoleon manuscripts no longer has the > right file date? ;-) > > Are there any practical uses of representating dates between 1772 and 1900 > on CD/DVD? > Unlikely, furthermore, the spec explicitly states that the number is unsigned (ref: ECMA-119, 2nd ed, 9.1.5 which specifies that the numbers are "recorded according to 7.1.1"; 7.1.1 specifies "8-bit unsigned numerical values"). -hpa From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from terminus.zytor.com ([198.137.202.10]:53117 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753026AbaEaIsC (ORCPT ); Sat, 31 May 2014 04:48:02 -0400 Message-ID: <53899717.1050109@zytor.com> Date: Sat, 31 May 2014 01:47:19 -0700 From: "H. Peter Anvin" MIME-Version: 1.0 Subject: Re: [RFC 06/32] isofs: fix timestamps beyond 2027 References: <1401480116-1973111-1-git-send-email-arnd@arndb.de> <1401480116-1973111-7-git-send-email-arnd@arndb.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-arch-owner@vger.kernel.org List-ID: To: Geert Uytterhoeven , Arnd Bergmann Cc: "linux-kernel@vger.kernel.org" , Linux-Arch , "Joseph S. Myers" , John Stultz , Christoph Hellwig , Thomas Gleixner , Ley Foon Tan , Linux FS Devel Message-ID: <20140531084719.ZXCKBgYpP2j9XJnAdbGebvN_S-laaNy1rfhS_86hg2A@z> On 05/31/2014 12:59 AM, Geert Uytterhoeven wrote: > On Fri, May 30, 2014 at 10:01 PM, Arnd Bergmann wrote: >> isofs uses a 'char' variable to load the number of years since >> 1900 for an inode timestamp. On architectures that use a signed >> char type by default, this results in an invalid date for >> anything beyond 2027. >> >> This adds a cast to 'u8' for the year number, which should extend >> the shelf life of the file system until 2155. > > Oops, the CD archive of my scanned Napoleon manuscripts no longer has the > right file date? ;-) > > Are there any practical uses of representating dates between 1772 and 1900 > on CD/DVD? > Unlikely, furthermore, the spec explicitly states that the number is unsigned (ref: ECMA-119, 2nd ed, 9.1.5 which specifies that the numbers are "recorded according to 7.1.1"; 7.1.1 specifies "8-bit unsigned numerical values"). -hpa