alessandro wrote: > On Mon, 17 Aug 2009 11:32:56 +0200 > Karel Zak <kzak@xxxxxxxxxx> wrote: > > > > Looking at the other rtc drivers, some of them *do* set tm_isdst to -1, > > > some of them (especially rtc-efi) set tm_isdst to real data ... so I'm > > > not sure this patch to rtcwake will work right on EFI based systems. > > > > > > Would it be better to say this is a kernel RTC driver problem, in that > > > it is returning 0 instead of -1 in tm_isdst? > > > > Redirecting to RTC guys, see > > http://thread.gmane.org/gmane.linux.utilities.util-linux-ng/2516 > > I'm inclined to say that the whole DST thing is an userspace > problem and that all hardware clocks should be set to UTC :) :-) > > or rtc_read_alarm_internal could be patched > to initialize that field to -1 prior to the call to ops->read_alarm i don't think that's sufficient (or even, perhaps, necessary) -- is it? it's not reading the alarm time where the problem lies. as james cameron pointed out, the issue is that ioctl(fd, RTC_RD_TIME, &rtc) returns a bogus '0' value in the tm_isdst field. the kernel and RTC drivers should be fixed to contrive that this field is reported reliably as "don't know", i.e. -1. but this begs the question: does any RTC chip actually implement DST? i'm inclined to say no, given a brief survey of drivers, and the fact that rtc_time_to_tm() doesn't even bother with that field. how could it, after all -- as you say, it's really a userspace problem. so i guess i still think that although the kernel should be fixed to do the right thing with tm_isdst, it would be entirely appropriate for rtcwake to ignore the tm_isdst value (as proposed in my patch), and that would probably be correct for quite a long time. paul =--------------------- paul fox, pgf@xxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
