the default time uint is millisecond while ndn-cxx uses nanosecond
This causes problems when programs based on ndn-ccl libraries need to communicate with problems based on ndn-cxx
#3 Updated by Jeff Thompson over 1 year ago
Actually, the jNDN fromTimestamp and toTimestamp just encode and decode the number that it is given, without converting them. The timestamp is defined to be "Number of microseconds since UNIX epoch" in the Name Conventions document: http://named-data.net/doc/tech-memos/naming-conventions.pdf
ndn-cxx uses Boost time functions which force things to nanoseconds. But jNDN doesn't use Boost. The Common Client Libraries API is designed to be consistent across languages like Java, Python, etc. It is not hard-wired to Boost like ndn-cxx.
#4 Updated by Haitao Zhang over 1 year ago
I need to correct myself first: ndn-cxx uses "microseconds", which is consistent with the Name Conventions document; while ccl uses "milliseconds".
I agree that it's a good that ccl libs API is designed to be consistent. My concern is, a timestamp component is interpreted differently by ndn-cxx and ccl; however, in theory, all interpretations should be consistent with the Name Conventions document.