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 problem.
See http://www.w3.org/TR/timezone/ for some of recommendations.
/ Alexander Bokovoy
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code