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)
NEW
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.
Comment 1•22 years ago
|
||
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>.
Updated•21 years ago
|
QA Contact: bishakhabanerjee → jason.m.reid
| Reporter | ||
Comment 4•20 years ago
|
||
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
Updated•20 years ago
|
Assignee: wtchang → nobody
QA Contact: jason.m.reid → libraries
Updated•19 years ago
|
Priority: -- → P3
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•