This reminds me of the case where there are multiple possible delimiters - the one provided in the original file may not be the one that appears in the unparse output.
-----Original Message----- From: Steve Lawrence [mailto:slawre...@apache.org] Sent: Friday, January 8, 2021 9:18 AM To: dev@daffodil.apache.org Subject: Timezones in DFDL I was confirming that DAFFODIL-1580 [1] is still an issue and was going to open a bug with ICU, but as I look more at this, I think this is just a limitation with timezones and DFDL, but wanted confirmation first. For example, we have a test schema that looks like this: <xs:element name="time" type="xs:dateTime" dfdl:calendarPattern="hh:mm.VVVV" ... /> And matching data that looks like this: 8:43.Los Angeles Time This parses to an infoset that looks like this: <time>08:43:00-08:00</time> And that infoset unparses to this: 08:43.GMT-08:00 Note that the unparsed timezone does not match the original data. DAFFODIL-1580 describes this behavior as a bug (either in Daffodil or ICU) but I think this is actually expected behavior. A DFDL infoset does not contain any location-specific timezone information--it only contains a GMT offset (a restriction of XML Schema). So this data will always unparse to a non-location specific timezone, depending on the calendar pattern. For some patterns this will be an offset or a generic timezone like PST (which should both roundtrip fine), but others might result in "Unknown" or "unk". I think this only affects the "V" and "v" calendar patterns, but additional tests should be added to confirm this behavior. This is the expected behavior, correct? [1] https://usg02.safelinks.protection.office365.us/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FDAFFODIL-1580&data=04%7C01%7Clarry.barber%40nteligen.com%7Ced53e6d6768e41dca6ec08d8b3e041ae%7C379c214c5c944e86a6062d047675f02a%7C0%7C0%7C637457123063759940%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hV8nkoGDxv039R6ZVkVwfYB%2BaUAIG3YLt3aRfebTrMI%3D&reserved=0
