Endi Sukma Dewata wrote:
> 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.
>
Yes. This is exactly the problem I am concerned about.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to