Open rjmccann101 opened 2 years ago
So changing AsDateTimeOffset to parse dates without explicit TimeZone information doesn't work - it breaks lots of tests in other code because what couldn't be inferred as a DateTimeOffset now can be and types change from DateTime to DateTimeOffset.
I believe it comes from the XML type xs:datetime getting mapped to DateTimeOffset
via XmlTypeCode.DateTime -> typeof<System.DateTimeOffset>
.
Given the discussion of time zones specificions in XML here (? is this the best source) it might make sense for the type provider to conditionally infer xs:datetime
to either be System.DateTime
or System.DateTimeOffset
based on the sample format, thought that's a bit annoying.
We had some discussions around this topic a long time ago (see #1181 and #980) and we settled on a sub-optimal solution also to avoid impacting the existing stuff. But I hope you can improve on this.
My preferred workaround, in cases like this, is to avoid accessing the generated property and use instead theXElement
property. The generated types in fact are just wrappers around and an XElement
and exposing the underlying XML I think it's been a very pragmatic and effective choice, allowing to use raw XML when necessary.
When a .xsd file is used to create the XML TypeProvider type from a .xsd and when the .xsd uses
xs:dateTime
then if when the date is parsed into aDateTime
structure it does not set theDateTime.Kind
to something other thanDateTimeKind.Unspecified
an error will be raised when attempting to read the date value.For example: given the following xsd fragment
and the following xml
<XMLTimeStamp>2022-04-28T10:09:17</XMLTimeStamp>
the following error is generated when trying to access the XMLTimeStamp
The issue is the code in
AsDateTimeOffset
in FileConversions.fsWhen the date is
2022-04-28T10:09:17
themd.Kind
is set toDateTimeKind.Unspecified
when parsed into aDateTime
byParseISO8601FormattedDateTime
and the code returnsNone
. Changing the date2022-04-28T10:09:17Z
causes thed.Kind
to be set and the date gets returned correctly.One possible solution would be to mimic what
AsDateTime
, which is used whentype=xs:date
, does which is to give the DateTime theDateTimeKind.Local
Kind when none is specified. This would change the code to something like this:This also removes the double parsing of the date string that currently takes place.
An alternative and even simpler approach would be to ignore the fact that
DateTimeKind.Unspecified
is used, we still have a valid date and can construct a valid DateTimeOffset from it.