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: > > > http://www.intelliadmin.com/images/Logon%20Hours%20Windows%20Active%20Directory.jpg > > > > > > 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 > problem. > > 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. Nathaniel -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
