I think the proposal covers your two main requirements.

i.e. Any date can be represented by seconds since an epoch (int64 allows us enough seconds to cover 292,471,208,677 years), so this format allows any language to serialize an instant in time, no matter the resolution of your language (nanoseconds, milliseconds, seconds, etc).

Your request for supporting Not-A-Date can be accomplished by encoding Nil (ie 0xc0).

Maybe I'm missing your point? If so, please clarify. I fail to see how this proposal doesn't cover your requirements.

I am sorry. I think I skipped over a point.

If we allow the deserializer to map a MessagePack type to a built-in type using a narrower definition (i.e. do not fullfill the third requirement), can we still satisfy the first requirement (i.e. map MessagePack DateTime type to JavaScript Date)? If we do, then I have two questions.

Q1. What happens when the MessagePack type cannot be mapped to the built-in type? (i.e. what does happen when a JavaScript binding receives a MessagePack DateTime value that cannot be mapped to the built-in Date object?)

Q2. IMO there should be a way to decode (and encode) the data that cannot be mapped to built-in types. How should we define such API? (i.e. are we going to introduce another DateTime object (other than the built-in Date type) that fully covers the semantics of the MessagePack DateTime type? How should we design such API?)

Personally I do not have a good answer to the questions although IMO there should be if we are going to introduce a single DateTime type. And such answer should exist for languages other than JavaScript with built-in DateTime types.

This is the reason why I wrote as follows (please accept my apologies for skipping the point).

If we are going to introduce a single (unified) DateTime type, I doubt if such requirements can be met. And that is the reason why I am skeptical at trying to introduce such single type.

How about taking a two step approach instead of trying to introduce a single DateTime type at MessagePack level at this moment? Once we introduce the extension mechanism, then we can first test ideas (such as adding a DateTime type) in the wild without sacrificing compatibility using an application-level extension. And if the test succeeds and the idea proves to be benefitial to many of the applications, then we can consider of promoting it to a MessagePack-level type (that uses one of the reserved tags).

The shortcoming of the approach is that we would need to renumber the extension (to reserved area). But IMO the renumbering process could be eventual, i.e. during the transition two tag IDs could mean the same thing. Another scenario is that people would start to consider the tag ID of the application-level DateTime type as a de-facto standard (such cases exist in other areas, i.e. TCP/UDP port numbers above 1024 are handled as such for certain protocols). Under such scenario we would not need to renumber the tag ID at all.

@ugorji
Apart from the discussion whether we should try to introduce DateTime type as part of the MessagePack spec., I would like to discuss on how a DateTime type should be serialized.

Your proposal says:

timestamp is represented as a sequence of 1, 2 or 3 integer values in msgpack format.

Using the key:

secs = seconds since unix epoch, up to int64 value
nsecs = fractional seconds as nanoseconds, up to int32 value
tz = timezone in quarter-hour offset from UTC, + 48 (a positive fixnum value)

If we are to define the type using one, two or three numbers as you describe, I think we should not use MessagePack types for encoding each of them. Raw representation should better be used. I mean that the type should be defined as below struct in C level (big endian, no padding, succeeding elements can be ommited):

struct {
  int64_t secs;
  int32_t nsecs; /* may be omitted */
  short tz; /* in minutes, may be omitted */
};

The reason to define as such is because it is simpler and not redundant (thus more secure).

PS. I do agree that the Date type of JavaScript is not defined in a elegant way.

Support timestamp as new spec-defined inter-operable extension type. #130

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions