Difficult to read errors for datetime objects that are not timezone aware

[h-mayorquin]

This comes from helping someone in dandi help desk as described here:

dandi/dandi-cli#1640

The user has an NWB file built with MATLAB that includes datetime objects without timezone information.

When I use the inspector to check the file I get this super long construction error that is not easy to read. Moreover, with 3,044,533 lines I find it unreasonable long:

cat nwbinspector  ../P22_1120_FBL_04272014_2.nwb | wc -l
nwbinspector  ../P22_1120_FBL_04272014_2.nwb > error_no_timezone.txt

error_no_timezone.txt

In pynwb 3.0.0 I am unable to open his file:

and the error is not that complicated.

But given that the inspector is meant to be used by matlab users as well (when they upload to dandi) maybe this type of error should surface in a more user friendly way? Is there a way to improve this?

[stephprince]

I think this is partially an issue in PyNWB in that we should still allow a user to open an NWB file even if timestamps_reference_time is not timezone aware. This PR that was merged into PyNWB and should be included in the upcoming release will allow files to be opened even if the timestamps_reference_time is timezone naive: NeurodataWithoutBorders/pynwb#2056

There is a separate issue I think as to whether this should be caught with pynwb-validate or the inspector, I will take a look at the issue you opened for that on the pynwb side.

[h-mayorquin]

Great. Thanks, @stephprince . Once NeurodataWithoutBorders/pynwb#2056 is released and I can revisit the errors here on the inspector to see if there is anything to be improved upon.

[stephprince]

@h-mayorquin I tested a file where 'timestamps_reference_time' was not timezone-aware with the latest version of PyNWB and it seems the inspector output is now a reasonable length. There is an open issue to catch these timezone cases in the pynwb/hdmf validator - hdmf-dev/hdmf#1284.

However I took a look at some other io.read() related errors and they tend to be long and difficult to interpret in general. One reason is that io.read() errors are caught twice when using the CLI. Another reason is that the exception and full traceback are both printed out, which in this specific case includes the entire builder for the NWB file.

I think we can simplify this output to hopefully make it clearer to users where these errors are coming from while keeping it interpretable for debugging. I've opened up a related draft PR #603, let me know if you have any thoughts!