daniel@pluta.biz wrote:
Michael Ströder schrieb:
daniel@pluta.biz wrote:
Even with the above described limited scope there seem to be plenty of open questions before thinking about "office-hours" and so on. Just two examples regarding the current implementation of now:
- The server's timezone vs. the client's timezone (that's more or less
obvious - in my opinion it's sufficient to store UTC times).
Yes, time is always stored in UTC in the server.
- Replication of "now" attributes' values between slapds that are
located in different timezones and client's that communicate with these server's...
IMHO the client has to convert all user input to GMT and convert all server results to local timezone for presentation to the user. The server internally processes everything as GMT. Maybe I got you wrong though. Other server implementations do it this way when checking logon hours.
The server internally compares the (once set) attributes' values against its current time (whether locale or utc, does not really matter here essentially it's always used the same - utc or local time) but the server does not know (IMHO it cannot reliably determine) from which timezone a client currently is connecting. Imagine a business trip to Japan (GMT+10) login would not work during the original specified (European) office hours, even when asking a local replica server in Japan...
Right. Which is a good argument against centralized enforcement of general logon hours, since only the client knows what timezone is relevant.
Of course, a company with offices in many timezones, and standardized working policies, might use such a mechanism to control the electronic door locks in all of their buildings. In that case it would make sense for the client software to treat the in-directory times as zoneless, or localtime...
But I agree, a discussion of how to manipulate timezone information is outside the scope of this ITS.