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. > I'm not against to change. But don't want to change this multiple > times, and step by step. It is why I'm asking. :-) Agreed. > 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. 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! 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? Also see https://bugzilla.suse.com/show_bug.cgi?id=912583#c33 and ff Volker -- Volker Kuhlmann http://volker.top.geek.nz/ Please do not CC list postings to me. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
