Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp7603035ybl; Thu, 16 Jan 2020 02:27:35 -0800 (PST) X-Google-Smtp-Source: APXvYqyv9LTL4o1zfZoLo1Wp5iKJaPaKrh/Dw7BcpcPXSVvztEUHVqQVrEHQowxueW4IqjzmQtWW X-Received: by 2002:a9d:7517:: with SMTP id r23mr1307938otk.235.1579170455395; Thu, 16 Jan 2020 02:27:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579170455; cv=none; d=google.com; s=arc-20160816; b=LNhWK3TKjbcPjLdx6b2/n9CDsbHPSIoCdM/1NkIoPAcFxj5lTAHgL28ztiPqOi0rnm xzT6IUQWU2X32GqfkbOv3D8oLbdCq1EhXa2+FwpVJ8LLEp9ktZhLKXzJr9vgTytIJgAN F/a8K/njMIU7ZcRSAXvtktKkvDsebc/xjNP2RbsMO/n/5qmUvmZLZ8gYMAQimELfZk7v vXzkH2ZsiaHfs4IMT0AVl+PWPNND5udngebMoIIZFqXSjmEgGmf2Z6CR0F+9TUAuCNu/ TELFo+MCDhtk7k+OP2/juu09dh5gNLPDLA5t9q38oPesxMTwJSTG4YNuCvjux00+WsGr XQ3Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=PqW95yCnuGXyfCxMcpfZuMgnSchIlTcfKX/rgIqE+TU=; b=aSSdVxOpebq6frAFdyPcYD+nVsnskSG7nYgFCaVY/buA8Zjre3RVF9sKw07/huTvcx l7+KTKSqcP8ITs7lnzXOtpolHBhhsgOjcSOuoDJYcr8KDkxyunhZJDUkh+N8B6+fwfN3 OnjTGxouUN0ohO0XaDHyGbTMCOjKSgG3CO2x6FVUJqog4ffD9OMKUaNFBqDYooFx9EqR 8EuHoyEQWUl2M3bmUpWM1t5Lo+8vTX+ZA1BV3QsVk6XprH+UEf1HVVQkBgCtlQ0cJ9rx +skZLCFAk9xJzKicKb6ca0zcqiC3jYGT8C2Lg5uiz8sQ8rkGgHEPloJ0AqAk6sBfilOP BgyQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p25si11685815oto.191.2020.01.16.02.27.23; Thu, 16 Jan 2020 02:27:35 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726871AbgAPKXK (ORCPT + 99 others); Thu, 16 Jan 2020 05:23:10 -0500 Received: from verein.lst.de ([213.95.11.211]:55239 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726220AbgAPKXK (ORCPT ); Thu, 16 Jan 2020 05:23:10 -0500 Received: by verein.lst.de (Postfix, from userid 2407) id 860F468B20; Thu, 16 Jan 2020 11:23:07 +0100 (CET) Date: Thu, 16 Jan 2020 11:23:07 +0100 From: Christoph Hellwig To: Pali =?iso-8859-1?Q?Roh=E1r?= Cc: Arnd Bergmann , Namjae Jeon , Namjae Jeon , "linux-kernel@vger.kernel.org" , Linux FS-devel Mailing List , gregkh , Valdis Kletnieks , Christoph Hellwig , sj1557.seo@samsung.com Subject: Re: [PATCH v10 09/14] exfat: add misc operations Message-ID: <20200116102307.GA16662@lst.de> References: <20200115082447.19520-10-namjae.jeon@samsung.com> <20200115133838.q33p5riihsinp6c4@pali> <20200115142428.ugsp3binf2vuiarq@pali> <20200115153943.qw35ya37ws6ftlnt@pali> <20200116101947.4szdyfwpyasv5vpe@pali> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200116101947.4szdyfwpyasv5vpe@pali> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.