Any interest in datetime/timestamp native types?

[Jay Pipes]

Hi all,

I was wondering if there would be any interest in some patches that add a native ISO8601 timestamp type to the Cap'n'proto schema language? I've been playing around with capnp and love the project, but have had to write a bunch of shim code to translate to and from strings to datetime objects in Python and figured it would be nicer to just have a native timestamp type in capnp that the code generators could parse and do the translation properly. Anyway, if there's some interest, I'll throw something together as a proof of concept.

All the best,

-jay

[Kenton Varda]

Hi Jay,

The right way to represent a timestamp in Cap'n Proto is as a 64-bit number counting seconds, milliseconds, microseconds, or nanoseconds since Jan 1, 1970. I usually write something like:

  using TimePointInNs = UInt64;

  # Nanoseconds since the epoch.

  struct Foo {

    timestamp @0 :TimePointInNs;

  }

I think using any other representation for dates would go against the Cap'n Proto philosophy, since a simple integer counting seconds is the most convenient format for computation, and Cap'n Proto is all about optimizing for computation.

With that said, I can see an argument that the stringification code should be extended to recognize timestamps in some way for display purposes. There are a few ways this could be accomplished:

1) Define a standard struct type wrapping a timestamp, and special-case that in the stringification code. Unfortunately, in the absence of inline structs, this would have a pointer's worth of overhead for every timestamp.

2) Define a standard annotation to mark timestamps, and use that. Kind of ugly.

3) Define a custom type which is equivalent to Int64 but can be recognized by the stringification code. This would likely be far more intrusive than it is worth, so I don't recommend it.

I'm not particularly fond of any of these options. #1 is the most elegant but has unacceptable overhead. Perhaps if we eventually re-add inline structs to the language (they existed once, but were eliminated due to complexity) then #1 will make sense.

-Kenton

--
You received this message because you are subscribed to the Google Groups "Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an email to capnproto+...@googlegroups.com.
Visit this group at http://groups.google.com/group/capnproto.

[Jay Pipes]

Thanks, Kenton, that was kind of what I suspected, but figured it was
worth asking.

I guess option #2 would be what I would go with, actually. capnp already
defines standards for naming declarations. Standardized naming for some
"typedef'd" things like e.g. @iso8601_ts for an ISO-8601 timestamp
encoded as a UInt64 would allow folks to write hooks in the code
generators that added additional translation tooling for such things.

Anyway, just a thought. Again, thanks for a great library. Really diggin
it :)

All the best,
-jay

> On Thu, Dec 25, 2014 at 6:51 AM, Jay Pipes <jayp...@gmail.com
> <mailto:jayp...@gmail.com>> wrote:
>
> Hi all,
>
> I was wondering if there would be any interest in some patches that
> add a native ISO8601 timestamp type to the Cap'n'proto schema
> language? I've been playing around with capnp and love the project,
> but have had to write a bunch of shim code to translate to and from
> strings to datetime objects in Python and figured it would be nicer
> to just have a native timestamp type in capnp that the code
> generators could parse and do the translation properly. Anyway, if
> there's some interest, I'll throw something together as a proof of
> concept.
>
> All the best,
> -jay
>
> --
> You received this message because you are subscribed to the Google
> Groups "Cap'n Proto" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to capnproto+...@googlegroups.com

> <mailto:capnproto+...@googlegroups.com>.

> Visit this group at http://groups.google.com/group/capnproto.
>
>

> --
> You received this message because you are subscribed to the Google
> Groups "Cap'n Proto" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to capnproto+...@googlegroups.com

> <mailto:capnproto+...@googlegroups.com>.

[Alex Elsayed]

I'll also note that the Linux kernel is moving towards 64-bit nanoseconds
since the Unix epoch for its internal representation, though userspace still
sees timespec/timeval/etc. Signed, that gets you to 22XX-ish, and unsigned
to 25XX-ish.

So on Linux systems, 64-bit ns is going to be the actual constraint on the
precision you can get from the platform anyway. Using a larger unit does
nothing but lose precision, and using a smaller one does nothing but lose
range.

Kenton Varda wrote:

> Hi Jay,
>
> The right way to represent a timestamp in Cap'n Proto is as a 64-bit
> number counting seconds, milliseconds, microseconds, or nanoseconds since
> Jan 1, 1970. I usually write something like:
>
> using TimePointInNs = UInt64;
> # Nanoseconds since the epoch.
>
> struct Foo {
> timestamp @0 :TimePointInNs;
> }
>
> I think using any other representation for dates would go against the
> Cap'n Proto philosophy, since a simple integer counting seconds is the
> most convenient format for computation, and Cap'n Proto is all about
> optimizing for computation.

<snip>

[JF Gauvin]

It would be interesting to add the annotation to the "using" declaration. But it's not compiling.

using TimePointInNs = UInt64 $iso8601;