On Mon, 09 Mar 2015, Nathaniel McCallum wrote:
On Mon, 2015-03-09 at 20:22 +0200, Alexander Bokovoy wrote:
On Mon, 09 Mar 2015, Jakub Hrozek wrote:
> On Mon, Mar 09, 2015 at 04:08:46PM +0100, Martin Kosek wrote:
> > On 03/09/2015 03:58 PM, Alexander Bokovoy wrote:
> > > On Mon, 09 Mar 2015, Martin Kosek wrote:
> > ...
> > > One of bigger issues we had was lack of versatile ical format
> > > parser to handle calendar-like specification of events -- we
> > > need to allow importing these ones instead of inventing our
> > > own.
> >
> > Good point. I wonder how rigorous we want to be. iCal is a
> > pretty powerful
> > calendaring format. If we want to implement full support for it,
> > it would be
> > lot of code both on server side for setting it and on client
> > side for evaluating it (CCing Jakub for reference).
> >
> > AD itself has much simpler UI for setting the access time, a
> > table like that:
> > 
> >
> > IIRC, they only store the bits of "can login/cannot login" for
> > the time slots.
> > That's another alternative.
> I don't think that's what Alexander meant, I don't think the
> client library should come anywhere close to the iCal format. We
> might want to provide a script to convert an external format, but
> that's about it.
> I thought we could simply reuse parts of the previous grammar,
> maybe simplified. But I agree with Nathaniel (as I stated also in
> the private thread) that we should use UTC where possible.
Yes and no. Let me go in details a bit.

We need iCal support to allow importing events created by external
tools. We don't need to use it as internal format.

However, there are quite a lot of details that can be lost if only
UTC would be in use for a date as you are ignoring a timezone
information completely. Timezone information needs to be kept when
importing and not always could be reliably represented in UTC so
that conversion from one timezone to another could present quite a

See  http://www.w3.org/TR/timezone/for some of recommendations.

I'm fine with a plan like this. I just want the admin to opt-in to
timezones. Localtime *by default* is fraught with pitfalls. If the
admin needs local time policy, he should specify it exactly and should
confirm the local time on affected systems.
Yep. We need to make it easy -- probably by allowing to define timezones
as part of host object (like Martin proposed) and overridden in HBAC
service/service group. And all this have to be very visual in the UI.

Another problem is how to deal with missing timezone information at the
place where HBAC rule with time rules would need to be applied. We need
to define the way we handle all these (unavailable, non-parsable and
other kinds of errors) timezone info issues.
/ Alexander Bokovoy

Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to