Re: date/time attributes

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

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.

-- 
Hallvard