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).aspx
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