Nope, details from the environment Daffodil runs in are never supposed
to be used for making parsing decisions. So whether you run Daffodil on
a machine in 2023 or 2024, you'll always get the same result.
Note that you can give your xs:dateTime and a pattern that does not
include a year field, but the spec says:
> When parsing, for any pattern that omits components the values for the
> omitted components are supplied from the Unix epoch
> 1970-01-01T00:00:00.000.[44]
So you would get the year 1970 in the infoset, so not particularly
useful if 2023 is supposed to be implied.
One option would be to parse the month/day components separately as
integers, and then parse the time separately as a xs:dateTime.
Another option, but more complex, would be to parse the field as a
hidden xs:dateTime with a missing year component from the
dfdl:calendarPattern, and then use an inputValueCalc on another element
with an expression to change the year from 1970 to 2023. Something like:
<element name="hidden" ... dfdl:calendarPattern="MMddHHmmssX" />
<element name="field" ... dfdl:inputValueCalc="{
xs:dateTime(fn:concat('2023', fn:substring(../hidden, 5))) }"
And if you wanted '2023' to be the current year, you could replace that
with an externally defined variable, and users calling parse would be
expected to set that to the current year.
That said, maybe an interesting extension property could be added to
define a different value for replacement components, e.g.
dfdlx:calendarReplacementComponents="2023-01-01T00:00:00.000"
Not a good name, but that's the idea. This would give you the 2023 year
you expect in the infoset instead of 1970. You would still need to
either change that property every year, or use a externally defined
variable and pass in the current year like mentioned above.
On 2023-11-03 01:39 PM, Roger L Costello wrote:
My input contains a month-day-hour-minute-timezone, e.g.,
.../09190935Z/...
I believe that the current year (2023) is implied. Is there a way to add the
current year so that the result of parsing is the standard datetime format?
E.g.,
<TimeOfReturnToOperations>2023-09-19T09:35:00+00:00</TimeOfReturnToOperations>
/Roger
