Created and LastModified use wrong extend from DateProperty

[derklaro]

Describe the bug
The classes Created and LastModified are both extending DateProperty<Instant> and UtcProperty which indicates that the return value of getDate should be a Instant representing a UTC timestamp. But in my case the return value of getDate is a ZonedDateTime.
To workaround the issue I am just getting the DateProperty and cast it to a ZonedDateTime:

        DateProperty<Temporal> creationTime = component.getRequiredProperty("CREATED");
        entry.setCreated(((ZonedDateTime) creationTime.getDate()).withZoneSameInstant(ZoneOffset.UTC).toInstant());

To Reproduce
Example VEvent which is causing the issue:

BEGIN:VEVENT
UID:12345@test.de
DTSTART;TZID=Europe/Berlin:20221108T090000
DTEND;TZID=Europe/Berlin:20221108T121500
DTSTAMP;TZID=Europe/Berlin:20221203T100650
LAST-MODIFIED;TZID=Europe/Berlin:20221108T182747
CREATED;TZID=Europe/Berlin:20220821T084513
SUMMARY:Test
DESCRIPTION:Test
LOCATION:Virtual-Room-26
END:VEVENT

Expected behavior
Either the created and LastModified classes are extening correctly from DateProperty or the return value of getDate is actually an Instant.

Screenshots

Environment (please complete the following information):

• OS: Windows 11 22H2
• Java Version 17.0.1 (2021-10-19 LTS)
• iCal4j Version 4.0.0-beta4

[douglm]

DTSTAMP, CREATED and LAST-MODIFIED are all required to be UTC times according to the standard.

…

On 12/3/22 04:17, Pasqual Koschmieder wrote: *Describe the bug* The classes |Created| and |LastModified| are both extending |DateProperty<Instant>| and |UtcProperty| which indicates that the return value of |getDate| should be a Instant representing a UTC timestamp. But in my case the return value of |getDate| is a ZonedDateTime. To workaround the issue I am just getting the DateProperty and cast it to a ZonedDateTime: DateProperty<Temporal> creationTime =component.getRequiredProperty("CREATED"); entry.setCreated(((ZonedDateTime)creationTime.getDate()).withZoneSameInstant(ZoneOffset.UTC).toInstant()); *To Reproduce* Example VEvent which is causing the issue: |BEGIN:VEVENT ***@***.*** DTSTART;TZID=Europe/Berlin:20221108T090000 DTEND;TZID=Europe/Berlin:20221108T121500 DTSTAMP;TZID=Europe/Berlin:20221203T100650 LAST-MODIFIED;TZID=Europe/Berlin:20221108T182747 CREATED;TZID=Europe/Berlin:20220821T084513 SUMMARY:Test DESCRIPTION:Test LOCATION:Virtual-Room-26 END:VEVENT | *Expected behavior* Either the created and LastModified classes are extening correctly from DateProperty or the return value of getDate is actually an Instant. *Screenshots* image <https://user-images.githubusercontent.com/40468651/205433603-3bcf1ac2-96f8-4d79-95c6-5380d29451d2.png> image <https://user-images.githubusercontent.com/40468651/205433618-45ec0535-d680-4c0a-b79a-5588a8ee9acd.png> *Environment (please complete the following information):* * OS: Windows 11 22H2 * Java Version 17.0.1 (2021-10-19 LTS) * iCal4j Version 4.0.0-beta4 — Reply to this email directly, view it on GitHub <#614>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAW2MBXH2XVXUTIQQA3ZBYDWLMFZ3ANCNFSM6AAAAAASSUUF7E>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[derklaro]

Hm, that kinda makes sense then... But I cannot access the data, I am just getting the exported data and I'm trying to parse it. It seems a bit odd that the time is parsed to something different anyway?

[benfortuna]

When we parse invalid properties such a CREATED with a non-UTC value, the intention is to try to convert to an equivalent valid value. In this case however, I think we currently just allow the ZonedDateTime to be parsed, but we aren't converting to an Instant value like we should (and also should only allow if RELAXED_PARSING flag is enabled).

I'll have a look to see if we can better enforce the typing for UTC properties.

Also note this related proposal to use ZonedDateTime instead of Instant for UTC properties, however I think there could be wider implications here which require further analysis.