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.

Yupp!

There doesn't appear to be any standardized syntax just for these purposes.

Let's refine this statement: There doesn't appear to be any standardized *LDAP* syntax just for these purposes. There is ISO 8601 though.

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...

The problem for a birthday is that you don't know the time and the time zone of the birth and you don't know the timezone in which to interpret (match) the date of birth. So I'm just using the simple date form with dashes of ISO 8601 (YYYY-MM-DD) which is a standardized syntax and readable just as is.

http://en.wikipedia.org/wiki/ISO_8601#Calendar_dates

There has been some opinions to use the date form without dashes to be able to restrict the attribute values to numbers by using LDAP syntax 'Numeric String'. But IMHO that's less user-friendly/readable.

Ciao, Michael.

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.