Timestamp (Common Typing Practices)

[ElizabethCapararo]

I am looking for some advice regarding the best data-type to store the following:

1. SQL DateTime
2. C# DateTime
3. Seconds (since 1960)
4. Milliseconds (since 1960)
5. Nanoseconds (since 1960)

I have had a read of the Kaitai typing, and am pulling data successfully from a file, my code to do so is below, but I'm getting strange results. I can attribute these to either:

• Rounded numbers from not using a large enough data type
• A blatant misunderstanding of Kaitai as I am a beginner

As per my last dot-point, I am a beginner when it comes to Kaitai, so give me as much information as possible. Whilst I have read everything I can think of to assist me with this, there's undoubtedly a lot I don't know.

See my code where I interpret it in several ways:

types:
  first_section:
     seq:
       - id: timestamp
         type: u8
  second_section:
     seq:
       - id: timestamp_two
         type: s4

[GreyCat]

I'm not sure what you mean by "SQL DateTime", as SQL is an international standard and, to best of my knowledge, does not introduce any restrictions or guidelines on serialization of its datatypes. Every ISAM engine does it differently.

"C# DateTime" is basically the same things as Windows FILETIME, i.e. a 64-bit little-endian integer counting number of 100-nanosecond ticks since 1601-01-01. Other formats mentioned also seem to be just integers.

From KS perspective, (2)..(5) are serialized as integers and should be just written down using u4 or u8 or something similar related to how the underlying integer is serialized.

If you want to get these to map into your target language's equivalent datetime datatype, though, that's another interesting story which is not yet implemented. Two options that can be explored are:

• using opaque types
• using schema-like approach that was suggested in https://github.com/kaitai-io/kaitai_struct/issues/188, but never fully formalized; this way we can "wrap" language-native types and concepts into KS-native types without resorting to totally opaque types