Hi, During the conversation with Ben and Kyle today over the calendar screen two things came up: 1) Time zone 2) Duration
Time zone It makes perfect sense to allow the admin to enter the rule and specify the time zone that the admin used to enter the time. Internally it will be converted to UTC but for the purpose of easier rule creation specifying time zone is helpful. Our grammar right now does not allow saving the zone since we plan to convert time to UTC, however when the value is fetched from the LDAP and presented for editing it is unclear which time zone it was entered in. Also there are two approaches to dealing with time zone information in general. Imagine you have a drop down with time zones. Imagine you entered time and then change the selected time zone in the drop down. Should the time you entered be automatically adjusted? First approach says "yes" but that means that we will have to implement a complex time recalculator since in corner cases the time difference between the time zones will affect the starting. The second option is to say: the time zone is just a specifier for the whole time rule indicating that the time values were entered in the given time zone. The when you change the value of the time zone you do not recalculate anything. With the right UI structure this can be made more obvious. However when the value fetched from the LDAP and displayed it might be useful to recalculate so I see two options how we can deal with the time zones. a) Do not save the time zone but recalculate the time (and date ???) when you change time zone in the drop down both in add and edit cases. When you fetch and display always use UTC but allow admin to change the "timezone view" at his will. b) Save time zone in the rule. As Simo pointed the time zone definition change from time to time so it makes sense to actually save offset and timezone as additional hint. This way we can easily convert the time stamp into the specified time zone and back at save and retrieval with no need to implement complex logic in the UI. IMO the second option is simpler but requires yet another change to grammar. I suggest we add offset and time zone as optional fields somewhere at the end of the rule or after start time. Duration New grammar allows DDHHMM for the duration. UI proposes to limit the duration to less than 24 hours since more than 24 hour windows can start overlapping and thus allowing to enter duration days was confusing to the users who tried the UI. We need to reconcile this a bit between what can be stored and what can be displayed. IMO it makes sense to allow windows more than 24 hours (regular service window over weekend for example). But on the other hand I see how having a separate field for number of duration days in the UI might be confusing. I would vote for not having days in the UI at all but allowing any numeric value to be entered into the hours field. This however rises a question whether we want to have the duration be in DDHHMM format in grammar or in just NMM format where N is any numeric value that represents unlimited number of hours. Thoughts? -- 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