--- CBOR-XS/XS.pm	2013/12/01 14:48:00	1.34
+++ CBOR-XS/XS.pm	2014/01/05 14:24:54	1.40
@@ -66,7 +66,7 @@
 
 use common::sense;
 
-our $VERSION = 1.11;
+our $VERSION = 1.25;
 our @ISA = qw(Exporter);
 
 our @EXPORT = qw(encode_cbor decode_cbor);
@@ -335,6 +335,70 @@
 
 =back
 
+=head2 INCREMENTAL PARSING
+
+In some cases, there is the need for incremental parsing of JSON
+texts. While this module always has to keep both CBOR text and resulting
+Perl data structure in memory at one time, it does allow you to parse a
+CBOR stream incrementally, using a similar to using "decode_prefix" to see
+if a full CBOR object is available, but is much more efficient.
+
+It basically works by parsing as much of a CBOR string as possible - if
+the CBOR data is not complete yet, the pasrer will remember where it was,
+to be able to restart when more data has been accumulated. Once enough
+data is available to either decode a complete CBOR value or raise an
+error, a real decode will be attempted.
+
+A typical use case would be a network protocol that consists of sending
+and receiving CBOR-encoded messages. The solution that works with CBOR and
+about anything else is by prepending a length to every CBOR value, so the
+receiver knows how many octets to read. More compact (and slightly slower)
+would be to just send CBOR values back-to-back, as C<CBOR::XS> knows where
+a CBOR value ends, and doesn't need an explicit length.
+
+The following methods help with this:
+
+=over 4
+
+=item @decoded = $cbor->incr_parse ($buffer)
+
+This method attempts to decode exactly one CBOR value from the beginning
+of the given C<$buffer>. The value is removed from the C<$buffer> on
+success. When C<$buffer> doesn't contain a complete value yet, it returns
+nothing. Finally, when the C<$buffer> doesn't start with something
+that could ever be a valid CBOR value, it raises an exception, just as
+C<decode> would. In the latter case the decoder state is undefined and
+must be reset before being able to parse further.
+
+This method modifies the C<$buffer> in place. When no CBOR value can be
+decoded, the decoder stores the current string offset. On the next call,
+continues decoding at the place where it stopped before. For this to make
+sense, the C<$buffer> must begin with the same octets as on previous
+unsuccessful calls.
+
+You can call this method in scalar context, in which case it either
+returns a decoded value or C<undef>. This makes it impossible to
+distinguish between CBOR null values (which decode to C<undef>) and an
+unsuccessful decode, which is often acceptable.
+
+=item @decoded = $cbor->incr_parse_multiple ($buffer)
+
+Same as C<incr_parse>, but attempts to decode as many CBOR values as
+possible in one go, instead of at most one. Calls to C<incr_parse> and
+C<incr_parse_multiple> can be interleaved.
+
+=item $cbor->incr_reset
+
+Resets the incremental decoder. This throws away any saved state, so that
+subsequent calls to C<incr_parse> or C<incr_parse_multiple> start to parse
+a new CBOR value from the beginning of the C<$buffer> again.
+
+This method can be caled at any time, but it I<must> be called if you want
+to change your C<$buffer> or there was a decoding error and you want to
+reuse the C<$cbor> object for future incremental parsings.
+
+=back
+
 
 =head1 MAPPING
 
@@ -801,6 +865,15 @@
 
 =over 4
 
+=item 0, 1 (date/time string, seconds since the epoch)
+
+These tags are decoded into L<Time::Piece> objects. The corresponding
+C<Time::Piece::TO_CBOR> method always encodes into tag 1 values currently.
+
+The L<Time::Piece> API is generally surprisingly bad, and fractional
+seconds are only accidentally kept intact, so watch out. On the plus side,
+the module comes with perl since 5.10, which has to count for something.
+
 =item 2, 3 (positive/negative bignum)
 
 These tags are decoded into L<Math::BigInt> objects. The corresponding
@@ -974,8 +1047,33 @@
 =cut
 
 our %FILTER = (
-   # 0 # rfc4287 datetime, utf-8
-   # 1 # unix timestamp, any
+   0 => sub { # rfc4287 datetime, utf-8
+      require Time::Piece;
+      # Time::Piece::Strptime uses the "incredibly flexible date parsing routine"
+      # from FreeBSD, which can't parse ISO 8601, RFC3339, RFC4287 or much of anything
+      # else either. Whats incredibe over standard strptime totally escapes me.
+      # doesn't do fractional times, either. sigh.
+      # In fact, it's all a lie, it uses whatever strptime it wants, and of course,
+      # they are all incomptible. The openbsd one simply ignores %z (but according to the
+      # docs, it would be much more incredibly flexible indeed. If it worked, that is.).
+      scalar eval {
+         my $s = $_[1];
+
+         $s =~ s/Z$/+00:00/;
+         $s =~ s/(\.[0-9]+)?([+-][0-9][0-9]):([0-9][0-9])$//
+            or die;
+
+         my $b = $1 - ($2 * 60 + $3) * 60; # fractional part + offset. hopefully
+         my $d = Time::Piece->strptime ($s, "%Y-%m-%dT%H:%M:%S");
+
+         Time::Piece::gmtime ($d->epoch + $b)
+      } || die "corrupted CBOR date/time string ($_[0])";
+   },
+ 
+   1 => sub { # seconds since the epoch, possibly fractional
+      require Time::Piece;
+      scalar Time::Piece::gmtime (pop)
+   },
 
    2 => sub { # pos bigint
       require Math::BigInt;
@@ -1021,7 +1119,7 @@
 sub URI::TO_CBOR {
    my $uri = $_[0]->as_string;
    utf8::upgrade $uri;
-   CBOR::XS::tag 32, $uri
+   tag 32, $uri
 }
 
 sub Math::BigInt::TO_CBOR {
@@ -1030,13 +1128,17 @@
    } else {
       my $hex = substr $_[0]->as_hex, 2;
       $hex = "0$hex" if 1 & length $hex; # sigh
-      CBOR::XS::tag $_[0] >= 0 ? 2 : 3, pack "H*", $hex
+      tag $_[0] >= 0 ? 2 : 3, pack "H*", $hex
    }
 }
 
 sub Math::BigFloat::TO_CBOR {
    my ($m, $e) = $_[0]->parts;
-   CBOR::XS::tag 4, [$e->numify, $m]
+   tag 4, [$e->numify, $m]
+}
+
+sub Time::Piece::TO_CBOR {
+   tag 1, 0 + $_[0]->epoch
 }
 
 XSLoader::load "CBOR::XS", $VERSION;