[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200116102307.GA16662@lst.de>
Date: Thu, 16 Jan 2020 11:23:07 +0100
From: Christoph Hellwig <hch@....de>
To: Pali Rohár <pali.rohar@...il.com>
Cc: Arnd Bergmann <arnd@...db.de>, Namjae Jeon <linkinjeon@...il.com>,
Namjae Jeon <namjae.jeon@...sung.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Linux FS-devel Mailing List <linux-fsdevel@...r.kernel.org>,
gregkh <gregkh@...uxfoundation.org>,
Valdis Kletnieks <valdis.kletnieks@...edu>,
Christoph Hellwig <hch@....de>, sj1557.seo@...sung.com
Subject: Re: [PATCH v10 09/14] exfat: add misc operations
On Thu, Jan 16, 2020 at 11:19:47AM +0100, Pali Rohár wrote:
> However, implementations should only record the value 00h for this
> field when:
>
> 1. Local date and time are actually the same as UTC, in which case
> the value of the OffsetValid field shall be 1
>
> 2. Local date and time are not known, in which case the value of the
> OffsetValid field shall be 1 and implementations shall consider
> UTC to be local date and time
Given time zones in Linux are per session I think our situation is
somewhat similar to 2.
> > Here I would just convert to UTC, which is what we store in the
> > in-memory struct inode anyway.
>
> Ok. If inode timestamp is always in UTC, we should do same thing also
> for exFAT.
> Hm... both UTC and sys_tz have positives and negatives. And I'm not
> sure which option is better.
The one big argument for always UTC is simplicity. Always using UTC
kills some arcane an unusual (for Linux file systems) code, and given
how exfat implementations deal with the time zone on reading should
always interoperate fine with other implementations.
Powered by blists - more mailing lists