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 [email protected] https://www.redhat.com/mailman/listinfo/freeipa-devel
