You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently DFDL binary timestamp representations are limited to 'binarySeconds' and 'binaryMilliseconds. Other 'tick' intervals have been observed in the real world, for example:
Windows FILETIME - 100ns
OPC-UA protocol - 100ns.
It would be useful for DFDL to be able to handle any 'tick' interval.
It would also be useful for DFDL to allow any length of binary timestamp - currently the lengths are fixed depending on the representation.
The other variable is epoch, but DFDL already allows the epoch start to be specified in a sufficiently flexible way.
These should be considered as candidate improvements for DFDL 2.0.
The text was updated successfully, but these errors were encountered:
Note: When creating a DFDL schema for NTP messages, there was a specific issue having to do with signed/unsigned integers being usable for creating seconds or milliseconds.... don't recall exactly, but this needs to be revisited to inform this issue.
Currently DFDL binary timestamp representations are limited to 'binarySeconds' and 'binaryMilliseconds. Other 'tick' intervals have been observed in the real world, for example:
It would be useful for DFDL to be able to handle any 'tick' interval.
It would also be useful for DFDL to allow any length of binary timestamp - currently the lengths are fixed depending on the representation.
The other variable is epoch, but DFDL already allows the epoch start to be specified in a sufficiently flexible way.
These should be considered as candidate improvements for DFDL 2.0.
The text was updated successfully, but these errors were encountered: