timezone date (was: Fwd: Manual Post Requested for draft-howard-rfc2307bis)
Michael Ströder <[email protected]>
| Newsgroups | gmane.ietf.ldapext |
|---|---|
| Message-ID | <[email protected]> |
Howard, do you think setting something like the timezone used for a user would be feasible? Or other Unix locale data? I raised this on [email protected] a couple of days ago and it could be related to your current work on that draft. Ciao, Michael. -------- Original Message -------- Subject: [ldap] Re: LDAP attribute type for timezone, retrieve locale for shell sessions Date: Thu, 13 Aug 2009 20:25:42 +0200 From: Michael Ströder <[email protected]> To: [email protected] CC: [email protected] References: <[email protected]> <1250172072.6473.14.camel@linux-m3mt> Adam Tauno Williams wrote: > On Thu, 2009-08-13 at 15:59 +0200, Michael Ströder wrote: >> Anybody aware of an attribute type dedicated to store the time zone of a user? > > Nope (but timezone codes are just strings). I think this would be the > 'default' timezone of a user; Hmm, frankly I'm not really familiar with this stuff. Looking at the timezone package on my Linux my spontaneous idea would be to add directory entries containing the compiled timezone blobs and a time zone attribute would just contain a DN as reference on this timezone blob entry. > but a user can easily move between time > zones. Yes, I'm aware of that. So the timezone setting in the directory entry should be kind of a self-service attribute. > It is actually pretty difficult [for scheduling applications] to > determine what is the correct thing to do with TZ sometimes. Well, calendaring software is not my primary goal. Rather simple things like displaying timestamps in local time in my web2ldap or correctly set the timezone-related env vars in a shell. The latter could be easily overridden by local shell profiles. >> It would also make sense if pam_ldap/nss_ldap could query the locale of the >> user from the user's directory entry and set the locale accordingly. Anybody >> doing something like this? > > Wow, that would be awesome. But I'm not holding my breath. ;-) Let's first discuss a data model... Ciao, Michael.