Re: (ITS#6247)

[michael@stroeder.com]

daniel@pluta.biz wrote:
> Some personal thoughts about locale (timezone) support. This seems to be
> by far out of scope and probably completely against the intention of
> "now.c".
> 
> How can the timezone be evaluated/specified? I think this can only be
> achieved on client-side by specifying some kind of +/-HHMM or
> timezone-strings in the matching rule's assertion...
> 
> This offers the possibility to chose a timezone on client side (e.g. a
> "window" of 46 hours) which is against the intention of "now".
> 
> now.c's original purpose is strictly limited and specialized on data
> privacy requirements. Only the server should decide about a currently
> (now) valid entry. I don't want to give a client the chance to variable
> request a timestamp (e.g by using a filter or even timezone) of
> "personal" interest.
> 
> 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).
> - 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.

Ciao, Michael.