Re: [SSSD] [Freeipa-devel] Proposed changes to the HBAC grammar
On 11/17/2010 3:21 PM, Dmitri Pal wrote:
> In a related note, we also discussed how to handle describing
activity
> windows that cross the midnight boundary. It's my recommendation that we
> should handle examples like the following by breaking them into two
> separate accessTime attributes, one that describes the portion preceding
> midnight and describes the set of days wherein the block starts, and a
> second accessTime attribute that is offset by one day and describes the
> portion taking place after midnight.
>
> Second-shift (17:00-01:59, M-S*) *starts Monday, ends Saturday morning
> becomes
> accessTime: periodic weekly day 1-5 1700-2359
> accessTime: periodic weekly day 2-6 0000-0159
I agree with the proposal the only issue I see is the issue of the time
zone of the user. When the user schedules the window it should be clear
what time zone he is using. If we in v2 use UTC for all I am fine but if
we allow user to enter window in the local time to his machine and then
rely on the client UI/CLI to convert it to UTC we can face a problem of
the local time window not crossing midnight while the UTC window will
cross the boundary. We need to define how this case will be handled and
how we interpret the input.
Will the user need to be aware of this issue? In other words, will the
UI enforce the user to split a schedule that crosses midnight manually?
If yes, there are some issues:
1. Some schedules that have to be split because of local time zone can
actually be merged in UTC. In that case do we want to merge it or keep
them separate? For example:
- Original: 2100-0159 local (UTC-3)
- Entered in UI: 2100-2359 and 0000-0159 local
- Stored on server:
a) keep the split schedules: 0000-0259 and 0300-0459 UTC
b) merge it: 0000-0359 UTC
2. Some schedules that have to be split because of local time zone may
need to be split differently in UTC. Will this confuse users? For example:
- Original: 2100-0159 local (UTC-2)
- Entered in UI: 2100-2359 and 0000-0159 local
- Stored on server:
a) split the first part: 2300-2359, 0000-0159, and 0200-0359 UTC
b) merge if possible: 2300-2359 and 0000-0359 UTC
Alternatively, the splitting issue can be hidden by the UI, but UI and
CLI will be inconsistent.
--
Endi S. Dewata