- Pete Rivett
- Maxwell Gillmore
- Cory Casanave
- Bobbin Teegarden
- Jefferson Braswell
- Elisa Kendall
- John Gemski
2) Composite Date Value Proposal
3) Contracts hierarchy and abstractions review
- along with review of Arrangements abstractions
4) FCT Changes / Use Case review
5) JIRA Issues Review
6) Where we are on our road map.
7) For next wee
FND 235 - proposal from EK to add a datatype and property to the dates ontology
John Gemski: Can you give the link for the new actions page?
EK - reusing hte same existing datatype (union of dateTime, dateTimestamp or string) - problem using the current structure with multiple restrictions. Proposing a composite date value in cermstances where comparisons are important
EK - new patters is for specific purposes (for efficiency) purposes - when challenges exist for mapping (one of hte three data types don't work)
TradeDate and SettlementDate (i.e. when optionality is needed) is the driver of the composite date
Varying registation dates - another example
PR - not keen on "name" (composite date and value might not be appropriate)
PR - potential redundancy for xsd: string
PR - dispute need for "hasReleaseDateTime"
PR - dispute need for hasReleaseDateTime "property" (he is OK with the data type)
EK - created the property hasReleaseDateTime for convenience (PR thinks it is the opposite)
EK - there are lots of examples where the datatype is used (hence the driver for the proposal)
FND group is in agreement on the value of the property hasReleaseDateTime
JG - would like two date representation (release date and event date - including time zone)
JG - the distinction btw release and event date is important for trading time stamp
EK - this can already be accomplished using existing date structures (does not allow for time stamp at nano-seconds)
JG - look at the problem from teh perspective of the business user who is evaluating FIBO from the CONCEPTS that they care about. Not only about how it might be implemented - must also include the concept
JG - two problems (for events need nano-seconds); #2 how to represent time zones (+/- UTC is ISO recommendation)
MG - future exercise date cannot be represented as an offset from GMT (in January you have a different time from June due to daylight savings time) - must be represented as "exercisable"
MG - "offset" is inadequate for any future event
EK - recognizes MG issue is important (unclear on how to address) - request examples for evaluation of options
EK - back to notion of "composite" - this could handle event dates (raise two issues (1) for nano-seconds (2) time zone challenge - do we need two datatypes to implement?
MB to raise JIRA issue on event dates
EK - back to naming issue (what is the alternative to "union" date)
PR - proposes "general" date as option
MB - proposes "combined date value"
Action - EK to research date naming convention options for consideration
John Gemski: Here's the problem. NYC is normally -5 UTC. For 2 weeks every year the US goes to DST 2 weeks before Europe. So for that 2 week period the time difference is -4 UTC and then it goes back to -5 UTC when Europe goes to DST. Problem is there's no conformity when time zones change between DST and standard time.
Jeff Braswell: What if an Occurrence is something that occurs over a range of dates and time ?
EK still sees value in keeping the property hiererchy for composite date (for rollup) as long as domain and range can be expressed
MB/EK to work offline to create a proposal for onward consideration
Jeff Braswell: A conference, or a music festival, or a business trip, etc
Jeff Braswell: debt instruments are also transferable, as are other contracts
- Mike Bennett Raise 2 new JIRAs, for date/time that includes nanoseconds, and for the ability to deal with tome zone differences.