[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Y2K patch for slapd -- modify/create timestamps



This is a good point.  I'd vote (if asked) to go the gmtime() route.
-Alan

-----Original Message-----
From: patl@phoenix.volant.org <patl@phoenix.volant.org>
To: OpenLDAP-bugs@openldap.org <OpenLDAP-bugs@openldap.org>
Cc: asparks@nss.harris.com <asparks@nss.harris.com>
Date: Thursday, October 15, 1998 3:12 PM
Subject: Re: Y2K patch for slapd -- modify/create timestamps


>> This minor patch clears a few 2-digit year references in slapd, to fix
the
>> modifytime and createtime automatic attributes
>>
>> ....
>
>That fixes the Y2K problem; but leaves another long-standing bug.
>The formatted time values end in 'Z', implying UTC (aka 'Zulu' time);
>but the values were obtained via localtime(3); so they will include
>the local timezone's offset.
>
>I believe that either the strftime(3) formats should end in '%Z'
>instead of a bare 'Z', to emit the correct timezone code; or the
>time values should be obtained via gmtime(3) instead of localtime(3).
>Another alternative would be to remove the Z entirely, thus implying
>an unspecified timezone offest.
>
>A case could also be made for inserting the optional delimiters
>specified in ISO-8601.  (e.g. '1998-10-15 14:56:16-8:00' or
>'1998-10-15 22:56:16Z' instead of '19981015225616Z'.)
>
>Note that ISO-8601 compliance also dictates that the timezone
>notation, if present, be either 'Z' for UTC or the offset from
>UTC in hours and minutes.  Timezone abbreviations are not allowed.
>Unfortunately, most implementations of strftime(3) do not have a
>format code for the offset notation.
>
>
>
>-Pat
>P.S. For info on ISO-8601, see:
> http://www.cl.cam.ac.uk/~mqk25/iso-time.html
>