[Date Prev][Date Next] [Chronological] [Thread] [Top]


Some personal thoughts about locale (timezone) support. This seems to be
by far out of scope and probably completely against the intention of

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