Ander Juaristi <a...@juaristi.eus> wrote:
> On 15/7/19 1:34, Florian Westphal wrote:
> > > Even when relying on kernel time zone for everything, I don't see
> > > how we can support cross-day ("22:23-00:42") matching, as the range is
> > > invalid.
> >
> > And that as well of course, swap and invert should work just fine.
> >
> > > Second problem:
> > > Only solution I see is to change kernel patch to rely on
> > > sys_tz, just like xt_time, with all the pain this brings.
> >
> > This stands, as the weekday is computed in the kernel, we will
> > need to bring sys_tz into this on the kernel side, the current
> > code uses UTC so we could be several hours off.
> >
> > This can be restricted to the 'DAY' case of course.
> >
>
> I see... Thank you. You saved me hours of work figuring this out.
Giving hints is what I am supposed to do :-)
> So, for the TIME case we just swap left and right, and for the DAY case,
> just add (tz_minuteswest * 60) to the seconds before breaking it into
> day/mon/year?
Yes, swap and eq -> not eq -- at least I think that should work and
would make something like 18:00-07:00 work.
> And what does tz_dsttime do? gettimeofday(2) man says it is there for
> historical reasons and should be ignored on Linux. But I don't know what is
> it for in the kernel.
The kernel has no idea what a time zone is, the tz_dsttime setting
comes from userspace, typically during boot via hwclock(8).
IIRC it only flags if we're in 'daylight saving time' or not,
i.e. 0 for CET and 1 in CEST case.
