hello,
how can i changed that openldap used the systemtime from my server to store it as modifytimestamp? in this time, openldap used the gmt time but in germany we have gmt+1+summertime (gmt+2).
and my system get me not the gmt time, the system get me the actual local time and i want that openldap stored the local time. when he stored the gmt time (current status), we have problems with applications by search for entrys that changed in the last hour.
(sorry for my bad english)
thank you very mutch Frank
Frank Lohfeld wrote:
hello,
how can i changed that openldap used the systemtime from my server to store it as modifytimestamp?
You can't.
in this time, openldap used the gmt time but in germany we have gmt+1+summertime (gmt+2).
and my system get me not the gmt time, the system get me the actual local time and i want that openldap stored the local time. when he stored the gmt time (current status), we have problems with applications by search for entrys that changed in the last hour.
It is your application's responsibility to convert between local time and GMT when interacting with the directory.
Remember that LDAP is a wide area system, accessible from anywhere in the world. Storing local time in the directory would be meaningless for clients that don't understand your timezone's rules, but all computer systems know how to handle GMT.
Howard Chu writes:
It is your application's responsibility to convert between local time and GMT when interacting with the directory.
Remember that LDAP is a wide area system, accessible from anywhere in the world. Storing local time in the directory would be meaningless for clients that don't understand your timezone's rules, but all computer systems know how to handle GMT.
That's not right. Remember that the Generalized Time syntax (used by e.g. modifyTimestamp) requires a suffix with the timezone: Either 'Z' for GMT, or '+/-hh[mm]'. Clients don't need to know any particular timezone's rules to handle that, they only need to know how to convert between specified timezones.
So OpenLDAP could be patched with an option to create attributes like modifyTimestamp: 20070419225007+0200 instead of modifyTimestamp: 20070419205007Z though I don't know how much code assumes the 'Z' format is used.
Hallvard B Furuseth wrote:
Howard Chu writes:
It is your application's responsibility to convert between local time and GMT when interacting with the directory.
Remember that LDAP is a wide area system, accessible from anywhere in the world. Storing local time in the directory would be meaningless for clients that don't understand your timezone's rules, but all computer systems know how to handle GMT.
That's not right. Remember that the Generalized Time syntax (used by e.g. modifyTimestamp) requires a suffix with the timezone: Either 'Z' for GMT, or '+/-hh[mm]'.
That's true, yes.
Clients don't need to know any particular timezone's rules to handle that, they only need to know how to convert between specified timezones.
In practice this is extremely easy to get wrong. It requires every client to do two transformations - one to convert local time to GMT, and one to convert stored time to GMT, before comparisons can be done. It also requires extra transformations in the server, since system time is always tracked in GMT. Keeping directory times in canonical form (GMT) means only a single (local to GMT) transformation is ever needed.
On Apr 19, 2007, at 1:54 PM, Hallvard B Furuseth wrote:
Howard Chu writes:
It is your application's responsibility to convert between local time and GMT when interacting with the directory.
Remember that LDAP is a wide area system, accessible from anywhere in the world. Storing local time in the directory would be meaningless for clients that don't understand your timezone's rules, but all computer systems know how to handle GMT.
That's not right. Remember that the Generalized Time syntax (used by e.g. modifyTimestamp) requires a suffix with the timezone: Either 'Z' for GMT, or '+/-hh[mm]'. Clients don't need to know any particular timezone's rules to handle that, they only need to know how to convert between specified timezones.
So OpenLDAP could be patched with an option to create attributes like modifyTimestamp: 20070419225007+0200 instead of modifyTimestamp: 20070419205007Z though I don't know how much code assumes the 'Z' format is used.
RFC 4517 says: The "Z" form of <g-time-zone> SHOULD be used in preference to <g-differential>.
The primary reason for this is interoperability. Not all implementations can deal (well) with g-differential. It should be avoided (on the wire).
-- Kurt
RFC 4517 says: The "Z" form of <g-time-zone> SHOULD be used in preference to <g-differential>.
The primary reason for this is interoperability. Not all implementations can deal (well) with g-differential. It
should be avoided (on the wire).
Another consideration is that g-differential may be different in a given location, depending on the date.
For example, in California, we are -0800 during the fall/winter and -0700 during the spring/summer due to daylight savings silliness.
Owen
Kurt Zeilenga writes: RFC 4517 says: The "Z" form of <g-time-zone> SHOULD be used in preference to <g-differential>.
The primary reason for this is interoperability. Not all implementations can deal (well) with g-differential. It should be avoided (on the wire).
Well, I'm not that eager for it.
Though I don't see that as much of a problem - in the sense that if the admin asks for it, it's his responsibility to deal with it. We've got other non-interoperability options too. Like {crypt} in userPassword, which even breaks the standard.
Owen DeLong writes:
Another consideration is that g-differential may be different in a given location, depending on the date.
For example, in California, we are -0800 during the fall/winter and -0700 during the spring/summer due to daylight savings silliness.
Which but the software only needs to know for its own host, and localtime() + strftime("%z & co") is supposed to take care of that.
openldap-software@openldap.org