Re: [PATCH v5 1/3] meta: Introduce new conditions 'time', 'day' and 'hour'

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ander Juaristi <a@xxxxxxxxxxxx> 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.



[Index of Archives]     [Netfitler Users]     [Berkeley Packet Filter]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux