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

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

Reply via email to