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

Logs show warning containing stack with ISO8601-compliant time intervals #2608

Open
MyForest opened this issue Oct 1, 2023 · 0 comments
Open

Comments

@MyForest
Copy link

MyForest commented Oct 1, 2023

Very much along the same lines as #2210, the use of isodate causes problems when parsing date intervals such as:

2023-10-01T22:15:00+00:00/2023-10-01T22:18:00+00:00

Now of course parseDatetime isn't intended to return an interval, so it's not clear what the right way to proceed is.

I've presented a test case demonstrating the problem in Missing support for time intervals so that the isodate team can see there are other scenarios where users of the function are tripping up.

As we can see in the test case, the value is round-tripping just fine because the Literal holds the supplied value.

The use of this dateTime format might occur when using http://purl.org/dc/terms/valid for example, because there is no validFrom and validTo.

Unfortunately the current behaviour causes noise in the logs of code using rdflib . I can suppress that like this:

logging.getLogger("rdflib.term").addFilter(lambda record:not record.msg.startswith('Failed to convert Literal lexical form to value.'))

but I wasn't able to work out how to do this with warnings. I believe we'd need to change the logger.warning to something like:

warnings.warn(
    f"Failed to convert Literal lexical form to value. Datatype={datatype}, Converter={conv_func}",
    category=UserWarning
)

which would allow users of rdflib to do this (example in code, but it could be in config):

import warnings
warnings.filterwarnings("ignore", message="Failed to convert Literal lexical form to value.", category=UserWarning)

As you've discussed this before, I suspect you've settled on logging it as a warning. Perhaps this is because the wide variety of causes means it would be very messy to handle conv_func specific outcomes.

Feel free to close this issue if there's no way to resolve this.

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

No branches or pull requests

1 participant