Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GH-4104: fix issue with Instant, turn it into datetimestamp value #4145

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

barthanssens
Copy link
Contributor

Signed-off-by:Bart Hanssens bart.hanssens@bosa.fgov.be

GitHub issue resolved: #4104

Briefly describe the changes proposed in this PR:

  • add formatter to convert Instant to xsd:dateTimestamp
  • added test

PR Author Checklist (see the contributor guidelines for more details):

  • my pull request is self-contained
  • I've added tests for the changes I made
  • I've applied code formatting (you can use mvn process-resources to format from the command line)
  • I've squashed my commits where necessary
  • every commit message starts with the issue number (GH-xxxx) followed by a meaningful description of the change

…amp value

Signed-off-by:Bart Hanssens <bart.hanssens@bosa.fgov.be>
@barthanssens barthanssens force-pushed the GH-4104-values-instant-xsdtimestamp branch from 9e49002 to bf6452a Compare September 2, 2022 14:25
Copy link
Contributor

@abrokenjester abrokenjester left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work @barthanssens - couple of minor inline comments.

Comment on lines +520 to +521
assertThat(literal.getDatatype()).isEqualTo(XSD.DATETIMESTAMP);
assertThat(literal.getCoreDatatype()).isEqualTo(CoreDatatype.XSD.DATETIMESTAMP);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the reasoning for using dateTimeStamp instead of just dateTime? As far as I'm aware the only difference is that the time zone is not optional in dateTimeStamp, but dateTime seems to be more far more commonly used.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately a bit of a hack... currently the DateTimeFormatter is selected based on the XSD type.

So for xsd:dateTime a DateTimeFormatter is selected that uses ChronoField.YEAR field etc, which is not supported by Instant...

Giving it a second thought.... Perhaps it could be implemented the other way round (always use a formatter using Chronofield.INSTANT_SECONDS for xsd:dateTime), though that would break if a Temporal would not support that field

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@barthanssens but regardless of which formatter you use, you could use the xsd:dateTime datatype URI for the resulting literal I think? Every dateTimeStamp is also a valid dateTime...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have to re-check the code, but I was under the impression that the current code first selects the xsd type on the chronofields of the java class, (where Instant does not support e.g. Year)
and then that xsd type is used to select the dateformatter

Instead of first do the formatting and then set the xsd datatype.

I'll look into it, I do agree that using dateTime for all cases is a better solution...

@barthanssens barthanssens marked this pull request as draft December 19, 2022 13:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Values.literal does not work for Instant
2 participants