CryptX
view release on metacpan or search on metacpan
lib/Crypt/ASN1.pm view on Meta::CPAN
epoch Unix timestamp (integer) dt => 'epoch' 1705314600
Both forms are accepted by the encoder. When C<format> is absent, the
encoder auto-detects: an all-digit value is treated as epoch, a value
matching C<YYYY-> is treated as RFC 3339.
For C<UTCTIME>, encoder input must fall within the UTCTime year window
C<1950..2049>; values outside that range are rejected. Fractional seconds
are also rejected for C<UTCTIME>.
Time validation in the encoder is currently B<syntactic>, not full calendar
validation. The encoder checks the accepted input shape and ASN.1-specific
constraints above, but it does not verify that every RFC 3339-looking date
and time is semantically valid.
The decoder expands the 2-digit UTCTime year using the RFC 5280 window
(YY E<gt>= 50 E<rarr> 19YY, else 20YY). Timezone offsets are preserved
(e.g. C<"2024-01-15T10:30:00+05:30">).
=head3 GENERALIZEDTIME
B<Keys>: C<type>, C<format>, C<value>.
Same C<format> rules as C<UTCTIME>; both forms are accepted by the encoder.
Fractional seconds are preserved (e.g. C<"2024-01-15T10:30:00.125Z">).
Validation is likewise syntactic only; semantically invalid calendar values
that match the accepted timestamp syntax are not currently rejected.
=head3 SEQUENCE
B<Keys>: C<type>, C<format>, C<value>.
C<value> is an arrayref of child node hashrefs (in order). C<format> is
always C<"array">.
{ type => "SEQUENCE", format => "array", value => [ ...children... ] }
( run in 0.667 second using v1.01-cache-2.11-cpan-f52f0507bed )