Closed donmendelson closed 6 years ago
Hi Don, Does this change require application using a default TimeUnit to specify TimeUnit on the wire nevertheless? For example we are currently using nanoseconds since Unix epoch consistently across all messages and schemas for all our UTCTimestamps. With the proposed change would we be required to encode nanoseconds as enumerated TimeUnit and send it on the wire with every UTC Timestamp? This would create a waste of bytes on the wire which we would want to avoid.
Rosa, see Time and Date Encoding in section 2 of v1.0 Standard. It shows how the timeUnit can either be sent on the wire or it can be set as a constant. This enhancement was made in v1.0 RC3.
This example is given of a constant timeUnit--8 bytes are sent on the wire:
<composite name="UTCTimestampNanos" description="UTC timestamp with nanosecond precision" semanticType="UTCTimestamp" >
<type name="time" primitiveType="uint64" />
<type name="unit" primitiveType="uint8" presence="constant" valueRef="TimeUnit.nanosecond" />
</composite>
I understand that constant is always an option, if the value is not changing and no need to send it on the wire, but is there an option in v.1.0 to keep UTCTimestamp as simple binary type (not a composite) for default TimeUnits? I think for the applications that already implemented SBE based on RC2 we should have a way to keep things simple and not unnecessarily impact our customers with template changes that default to the same data on the wire.
Hi again Don, Is v.1 xml validation going to fail on semantic type UTCTimestamp used with uInt64 type? Ex:
field name="LastUpdateTime" id="779" type="uInt64" description="Timestamp of when the instrument was last added, modified or deleted" offset="6" semanticType="UTCTimestamp"
@RFrenkel , if you are keeping the time unit constant at nanoseconds, then there will be no change to the wire format that you have been using. It will still be 8 bytes on the wire. However, there would be slight change to the XML metadata. You would use the composite type as shown above rather than just the primitive type.
Therefore, the two XML attributes may be removed in version 2.0 of the schema.
Don could you please specify which two attributes are being removed?
To be removed:
<xs:attribute name="epoch" type="xs:string" default="unix"/>
<xs:attribute name="timeUnit" type="xs:string" default="nanosecond">
No alternative was every offered for epoch, so it seems pointless. The timeUnit attribute lives on as a composite type member for UTCTimestamp.
In early drafts, XML attributes epoch and timeUnit were proposed. However, no other epoch was ever defined besides the UNIX attribute. TimeUnit is handled is handled in the wire format rather than just in metadata. Therefore, the two XML attributes may be removed in version 2.0 of the schema.