[Freeipa-devel] [SSSD] Proposed changes to the HBAC grammar

[Endi Sukma Dewata]

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