Comments (8)
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.
from fix-simple-binary-encoding.
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>
from fix-simple-binary-encoding.
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.
from fix-simple-binary-encoding.
Hi again Don,
Is v.1 xml validation going to fail on semantic type UTCTimestamp used with uInt64 type?
Ex:
from fix-simple-binary-encoding.
field name="LastUpdateTime" id="779" type="uInt64" description="Timestamp of when the instrument was last added, modified or deleted" offset="6" semanticType="UTCTimestamp"
from fix-simple-binary-encoding.
@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.
from fix-simple-binary-encoding.
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?
from fix-simple-binary-encoding.
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.
from fix-simple-binary-encoding.
Related Issues (20)
- Version 2 XML schema proposal HOT 1
- Invalid character in the v2-0-RC3\resources\xsd\sbe-2.0rc3.xsd HOT 1
- Possibly redundant "description" attrubute in the "semanticAttributes" attributeGroup HOT 5
- Decimal number representation for monetary amounts
- Version 2 RC schema does not allow semanticType on encoding types
- Clarify offset and length related types HOT 5
- How extension mechanism is supposed to work when dimension type is unknown? HOT 7
- Improve variadic-length field specification HOT 1
- Why is nullValue not allowed for required field? HOT 4
- Questions about common field attributes HOT 2
- How unique should message member's `id` be? HOT 3
- Why `symbolicName_t` is limited to 64 chars? HOT 3
- Can enum/set be optional? HOT 2
- Question: Forward compatibility between encoder code and schema version HOT 1
- Can `<field>` override presence of its type? HOT 2
- Schema extension mechanism violation
- SBE 2.0 features in 1.0 spec HOT 1
- Should `ref` use custom offset of the referred type?
- Better version constraints
- Ownership
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from fix-simple-binary-encoding.