Re: New feature: Extending timestamp format
Phelan, Nigel
If contemplating a new type, is it worth considering the question of time zones? The current model doesn’t really address this, although the java constructors have some implicit assumptions that DateTime objects are stored in UTC
Nigel
Nigel Phelan | Corporate & Investment Bank | Market Data Services | J.P. Morgan
From: openmama-dev-bounces@...
[mailto:openmama-dev-bounces@...] On Behalf Of Stuart Beattie
Sent: Wednesday, September 28, 2016 5:23 PM To: openmama-dev@... Subject: [Openmama-dev] New feature: Extending timestamp format
Hi everyone,
We are currently investigating an approach to improve and extend the handling of date/times in OpenMAMA.
The current mamaDateTime type, essentially being a 64-bit bitmask, is inflexible and has some built in limitations – such as the 4-byte second field limiting the maximum stored date to the year 2106, as well as being limited to time since the epoch. The current datetime format is this:
So while there are currently some bytes available to extend this somewhat, if these are used there will be no more room for expansion or new features in the existing format so we are thinking of a more long-term solution.
Instead we are proposing to introduce a new datetime format using a new type which is an actual struct with separate fields for the different elements (seconds, date, time etc.) While this may be larger (in terms of storage size – eg some bits may go unused), it would have the advantages of: a) Being more extensible – fields could be added or changed as necessary without being bound by the current 64 bits b) Being more intuitive to work with
Format could be something like:
This is in the early stages so we are asking for input as well as having a few specific questions for developers – with backwards compatibility being a major concern: - It is currently possible to serialise a mamaDateTime by using the native bitmask format directly – is anyone out there currently doing this and relying on this being possible? - For bridge developers, how do you currently encode timestamps? - Does anyone have any other suggestions for the new format? For example, nanosecond precision, addition of a timestamp, or any other useful features?
Thanks Stuart
STUART BEATTIE Senior Software Engineer
O. +44 28909 93365 M.
Adelaide Exchange Building, 2nd Floor, 24-26 Adelaide Street, Belfast, BT2 8GD velatradingtech.com | @vela_tt
This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email
|
|||||||||||||||||||||||||||||||||
|