Open Bug 227329 Opened 22 years ago Updated 3 years ago

GeneralizedTime decoder do not allow for leap seconds

Categories

(NSS :: Libraries, defect, P3)

Tracking

(Not tracked)

People

(Reporter: julien.pierre, Unassigned)

Details

In the case of leap seconds, seconds in UTCTime and GeneralizedTime can be 0 to 60, not 0 to 59, as enforced by our decoders. This is only valid if the time is 23:59:60 and at certain designated designed dates. We should fix this in DER_AsciiToTime and DER_GeneralizedTimeToTime to be allowed. Currently we consider seconds greater than 59 to be errors.
All leap seconds happen on the last day of the year, IINM so we should only allow them if mmddhhmm is 12312359, I think. (Maybe hour can be another value due to timezones, so maybe 1231xx59 is enough.)
Leap seconds can occur twice a year and can be either sign. See <http://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat>.
Sorry about the spam but see also <http://hpiers.obspm.fr/eoppc/bul/bulc/BULLETINC.GUIDE>.
QA Contact: bishakhabanerjee → jason.m.reid
In X.680, UTCTime does not support leap seconds. However, ISO 8601, which GeneralizedTime is based on, does . So we need to allow for a value of seconds of 60 for GeneralizedTime only.
Summary: UTCTime/GeneralizedTime decoders do not allow for leap seconds → GeneralizedTime decoder do not allow for leap seconds
Assignee: wtchang → nobody
QA Contact: jason.m.reid → libraries
Priority: -- → P3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.