Ildar Mulyukov wrote:
But I still fail to find any public attributes with SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 in OpenLDAP. But, if I'm not mistaken, this syntax IS implemented in OpenLDAP (comparison rules etc.).
OpenLDAP does use it for the operational attributes modifyTimestamp and createTimestamp. What you need is some schema which defines it though. Google "ldap schema vcard bday " found some stuff, including outdated internet-drafts, maybe you can use something there. or if you find nothing that fits your needs, you can get your own OID arc from IANA and define your own schema.
Howard Chu wrote:
GeneralizedTime can be pretty inconvenient when all you want to store is a date (for a birthday, etc.) or only a time. There doesn't appear to be any standardized syntax just for these purposes.
When I control the client and get to choose I prefer Numeric String, with yyyymmdd as the client-required date format. Numeric String allows digits and spaces, and comparison ignores the spaces. It doesn't prevent invalid dates, but it's a sufficiently restricted syntax that correct values get ordered correctly.
OTOH if the intended clients/libraries has more or less made the choice already, that's the end of it. E.g. if it supports translating between GeneralizedTime and friendlier date formats, but you can't expect them to have hooks to set them up to do the same with Numeric String.
E.g., if all you want is for your calendar to remind you of someone's birthday, you just need it to tell you on that given day. Your calendar program might put up an alert at 00:01 local time on that date. But "00:01 local time" is a floating time, while GeneralizedTime requires a specific time zone...
And time zones are why I prefer to avoid GeneralizedTime with a fixed (and hopefully client-ignored) time of day. A timezone-aware program might get friendly and adjust for local timezones - and maybe change the date while doing so. Could easily be more work to make sure various clients avoids that, than to implement the little extra functionality needed when using Numeric String.