On Thu, 18 Nov 2010 08:29:55 -0500 Dmitri Pal <d...@redhat.com> wrote:
> 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. > Ok there is an easy way to solve this. Instead of defining the interval as start-stop time we can define it as start-duration. This will remove any problem with crossing the midnight and will alow to make a 23:59 hours inteval starting at any time of the day. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
