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 )