Requirement to allow DFDL to understand Windows FILETIME type as well as Unix time type. Although DFDL allows the epoch to be specified via dfdl:binaryCalendarEpoch, it can only handle seconds or milliseconds. It would need to add a new binaryCalendarRep 'binaryTick' to handle the '100 nanoseconds' units. Regards Steve Hanson IBM Hybrid Integration, Hursley, UK Architect, IBM DFDL Co-Chair, OGF DFDL Working Group smh@uk.ibm.com tel:+44-1962-815848 mob:+44-7717-378890 ----- Forwarded by Steve Hanson/UK/IBM on 12/12/2017 09:48 ----- From: Andreas Martens1/UK/IBM To: Steve Hanson/UK/IBM@IBMGB Date: 08/12/2017 17:48 Subject: OPC-UA DateTime values Hi Steve, I'm working on processing OPC-UA DateTime elements, which are specified by: "A 64-bit signed integer representing the number of 100 nanoseconds intervals since 1601-01-01 00:00:00. This is the same as the WIN32 FILETIME type." (From OPC UA Part 3 - Address Space Model 1.03 Specification, available from opcfoundation.org) Now they might have been a bit conservative on the truth, here's Micosoft's specification: https://msdn.microsoft.com/en-us/library/windows/desktop/ms724284(v=vs.85).a... Which doesn't mention whether it's signed or not (in fact, it's split in two parts, potentially to maintain compatibility backwards (have thay always used 1601 as their epoch?)) typedef struct _FILETIME { DWORD dwLowDateTime; DWORD dwHighDateTime; } FILETIME, *PFILETIME; actually, DWORD is unsigned, so it's definitely unsigned, so OPC foundation are liars! cheers, Andreas -- Andreas Martens Emerging Technology IBM Research IBM Hursley Park, Winchester, SO21 2JN Phone: +44 (0) 1962 816833 37246833 www.emerging-technology.co.uk Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU