Best strategy to serialize date/timestamps [Java]

[Jayant Ameta]

I have a json file which contains timestamp in (yyyy-MM-dd'T'HH:mm:ss.SSS'Z') format. What's the best strategy for the schema file, since I would need to compare timestamps later on in my application.

Is there any way to do it without changing the format in my json file?

[Wouter van Oortmerssen]

Are these values not quoted? FlatBuffers does not support any special timestamp processing, so the only way to store them is as string (or integer, if you had a tool to convert them).

On Mon, Nov 20, 2017 at 1:59 AM, Jayant Ameta <witty...@gmail.com> wrote:

I have a json file which contains timestamp in (yyyy-MM-dd'T'HH:mm:ss.SSS'Z') format. What's the best strategy for the schema file, since I would need to compare timestamps later on in my application.

Is there any way to do it without changing the format in my json file?

--
You received this message because you are subscribed to the Google Groups "FlatBuffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flatbuffers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[mikkelfj]

As Wouter says, there is no native support.

If you do not need timezone information, a common way to represent time is to use seconds since Unix epoch first of january 1970. It can also be done with a 32 bit float value which is common in javascript. If you need nanosecond resolution then use nano seconds Unix epoch in 64 bit integers.

If space is of no signficance but timezone is (even if you don't know the timezone, but just wish to preserve the local time), then a string format in ISO 8601 is preferable, which is the format you already mentioned: https://en.wikipedia.org/wiki/ISO_8601 - a simplified version of this format is known as RFC 3339 which is also compatible with your format. Using RFC 3339 ensures that most recipients will have access to parse the format efficiently.

To use 8601 / RFC3339 in the most portable way, use the UTC (Zulu) timezone which easily translates to and from the numeric Unix epoch offset format.

A major weakness of the 8601 format is that time zone is only given as an offset, which does not handle daylight saving time and a lot of other special cases, but to keep it short, use the long IANA time zone name (e.g. "America/New_York" and a timestamp encoded in UTC (Zulu) time, if you need to go down that path. Avoid abbreviations because they are ambigious.

For efficient use with timezone you could create an enumeration of all the timezones that are relevant to you and map them to IANA long timezone names. Then store the timezone enum in one field as an 8 bit value and the timestamp as a 32 bit or 64 bit value depending on resolution. You would need to document your timezone mapping in order for recepients to understand the encoding. Alternatively you could store the timezone as an IANA string but share the string between all timestamps to save space.

https://en.wikipedia.org/wiki/List_of_tz_database_time_zones

On Monday, November 20, 2017 at 6:04:16 PM UTC+1, Wouter van Oortmerssen wrote:

Are these values not quoted? FlatBuffers does not support any special timestamp processing, so the only way to store them is as string (or integer, if you had a tool to convert them).

On Mon, Nov 20, 2017 at 1:59 AM, Jayant Ameta <witty...@gmail.com> wrote:

I have a json file which contains timestamp in (yyyy-MM-dd'T'HH:mm:ss.SSS'Z') format. What's the best strategy for the schema file, since I would need to compare timestamps later on in my application.

Is there any way to do it without changing the format in my json file?

--
You received this message because you are subscribed to the Google Groups "FlatBuffers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to flatbuffers...@googlegroups.com.

[mikkelfj]

I should clarify the point of storing timestamp in UTC and also have a timezone. This means that the reciepient can use a library to display the time in the given time zone, or alternatively use the time zone information to make certain decision such as whether it was within business hours, or if was dark, etc. The time zone is not used to adjust the timestamp because it is a unique point in time already given as a Unix epoch offset.