From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.parknet.co.jp ([210.171.160.6]:54209 "EHLO mail.parknet.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752028AbbKZEd2 (ORCPT ); Wed, 25 Nov 2015 23:33:28 -0500 From: OGAWA Hirofumi To: Volker Kuhlmann Cc: Jan Kara , linux-fsdevel@vger.kernel.org Subject: Re: [PATCH] fat: Allow time_offset to be upto 13 hours References: <1448466133-2838-1-git-send-email-jack@suse.cz> <13558026.NkMQpNgYP2@tui.site> <87poyx21cq.fsf@mail.parknet.co.jp> <5703679.3kKCzGj1xC@tui.site> Date: Thu, 26 Nov 2015 13:33:24 +0900 In-Reply-To: <5703679.3kKCzGj1xC@tui.site> (Volker Kuhlmann's message of "Thu, 26 Nov 2015 11:43:35 +1300") Message-ID: <87egfd1isr.fsf@mail.parknet.co.jp> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Volker Kuhlmann writes: > On Thu, 26 Nov 2015 06:52:37 OGAWA Hirofumi wrote: > >> > Or do you wish to track the legal time zone AND DST offsets in every >> > place in the world, make a list, stick that into the kernel, and >> > maintain it? I hope not. >> >> Actually, it is correct timezone support (for example, daylight). > > I don't get what you're trying to say here, sorry. Sorry, my bad english. I meant, using timezone database is only way to support correct timestamp for fat timestamp format. >> Well so, how does it overs 24 hours (i.e. a day) for sane tz offset >> (implementation is just a dumb adjustment of timestamp, but this >> option should means tz offset)? (And +-24 hours is used for TZ spec >> too.) > > +-24h offset for time zone (incl DST) should be sufficient. Yes. > However, asking the other way round, can someone please explain why > there needs to be a limit check? Will there be a kernel panic if someone > sticks in MAXINT? It's not the kernel's responsibility to enforce any > setting of user time! No strong opinion in my mind. But keeping it sane/predictable value would be better. > Perhaps the limit check should simply be removed? I can see e.g. using > this to correct for a past error in setting the time for the device the > vfat filesystem was created on. That would be cool... > Why enforce limits when you don't have to? Just because it fits the > programmer's limited view of use cases (see 12 + 1 = OOPS)? Or is this a > security problem? How about +-2years? Hm, not sure what usage it is. Why playing with timestamp for now? utimes(2) (and possibly UTC) simply? Thanks. > Also see https://bugzilla.suse.com/show_bug.cgi?id=912583#c33 and ff -- OGAWA Hirofumi