Closed CodyCBakerPhD closed 11 months ago
@CodyCBakerPhD Thanks for creating an issue here, I'll open a separate issue on neuroconv
soon. I switched to datetime.strptime
and with the expected format "%d-%b-%Y %H%M%S"
this example ('29-Apr-2020 16554') will be parsed as 2020-04-29 16:55:04
. Can we trust that?
Hmm... Because it scans left to right to grant precedence...
TBH the safest thing to do might be to simply capture it, warn the user, and fall back to using only the date?
timestamp_string = extracted_start_time.split(" ")[1]
if len(timestamp_string) != 6:
warn(f"Timestamp for starting time from openephys metadata is ambiguous ('{timestamp_string }')! Only the date will be auto-populated in metadata. Please update the timestamp manually to record this value with the highest known temporal resolution.")
extracted_datetime = datetime.strptime(extracted_datetime, "%d-%b-%Y")
else:
extracted_datetime = datetime.strptime(extracted_datetime, "%d-%b-%Y %H%M%S")
Yeah, agreed. I'll change https://github.com/catalystneuro/neuroconv/issues/576 accordingly.
This should also fixed by #32 once neuroconv
is updated as instructed in #29. Reopen if the issue persists.
Laurel found an issue on a new session
@weiglszonja Looks like this is a discrepency on the NeuroConv ophenephys side however, so that's where the true problem/fix is. Can you raise a separate issue over there when you make the PR?
As far as the actual core issue, it simply looks like the extra '16554' bit causes
dateutil.parser
to fail. It's not clear exactly what form it expects however, so we might want to swap todatetime.strptime
+ an explicit expected form. Also guessing the core issue there is that the string16554
could be interpreted as16:55:04
or16:05:54
but without the necessary zero padding it can't disambiguate. Not thatstrptime
would help with that...