Volker Kuhlmann <list0570@xxxxxxxxxxxxxxx> 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 <hirofumi@xxxxxxxxxxxxxxxxxx> -- 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
