On 3/23/2015 10:10 AM, Jan Cholasta wrote:

Dne 20.3.2015 v 13:30 Stanislav Láznička napsal(a):

As for the local time - timezone in the tuple (time, timezone) would
only say "Local Time", which can't be found in Olson's and it means the
time record from the tuple should be compared to the client's time
settings (/etc/localtime ?).

Let me just do a braindump here:

I would think timezone, or rather location (timezone + holidays) should be stored with user objects (but not in group objects, as users can be members of multiple groups, which could cause conflicts). When a user goes on a bussiness trip etc., an administrator/manager would need to change their location accordingly to reflect that.

For hosts, timezone information is already available on the host (/etc/localtime). I'm not sure if there is a 1-1 mapping between timezone and holidays, but if there is not, we probably need to store location with host objects as well. If we do that, maybe we can make SSSD update local timezone on the host using the information stored with the host object to allow roaming (think user laptops).

I'm not sure about storing the holiday information with any objects. Holidays are a good example for exceptions in time rules but I'm not sure that this information should be really stored with each user/host. There might be cases where you want the holidays to apply and then sometimes you may not want them to apply. Storing time exceptions with the specific HBAC rules would solve that, I think.
It might be a good idea to store optional owner information with hosts, so that when the owner moves to a different location, the host is assumed to be at that location as well (again think user laptops).

Given the above, HBAC rules could contain (time, anchor), where anchor is "UTC", "user local time" or "host local time".
Truth is, it was not really clear to me from the last week's discussion whose "Local Time" to use - do we use host's or do we use user's? It would make sense to me to use the user's local time. But then you would need to really store at least the timezone information with each user object. And that information should probably change with user moving between different timezones. That's quite a pickle I am in right here.

What would then be left to decide is whether to use the iCalendar time
format as internal, or use some other own created format. Such a format
should not only be suitable for reoccurring events, but should also be
able to handle exceptions in those events, such as holidays. It should
also be easy to import iCalendar events to this format to support events
from other sources.


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

Reply via email to