importing with from_Solis fails for acquired data timestamped with fractional seconds.

[DLafayetteII]

My new combination of Andor software with Ikon-M camera takes data where the date and time is recorded as such:
Date and Time: Tue Jun 30 10:44:22.653 2026
In WrightTools.data.from_Solis(), we take this string and throw it into time.strptime('Tue Jun 30 10:44:22.06 2026', "%a %b %d %H:%M:%S %Y"), which throws an error while the seconds has decimals:
"ValueError: time data 'Tue Jun 30 10:44:22.06 2026' does not match format '%a %b %d %H:%M:%S %Y'"
Previous data (from the Wright Group PL Table) was not exported with fractional seconds in the timestamp, so there was no issue.

While the time library does have the option of using %f to assign a value in microseconds, it does not appear that time.strptime cares about microseconds, so this information is discarded, we just want it to not stop the import. There are many ways to do this:

1. We could have a try and accept specific to this case
2. Given that we already assume the time format, we could separate the seconds portion of the string, round it, and recombobulate the string
3. We could loop and check that all numerical time components are nondecimal floats.

Given that this will make our code viable for use with new setups, it seems worthwhile to address. I can implement the update pending input on the preferred approach.

[ddkohler]

Unfortunate that import is so fragile that a slight timestamp change make the function fail. Definitely agree we should make this more robust.

I think I vote for a combination of 1 and 2 (but definitely 1).
That is, we can make a method separate the seconds portion and recast it as an integer (note that a regular expression is a powerful tool for doing this, and https://regexr.com/ is a great online tool for crafting your expression).

But even if we fix this particular formatting, it's quite possible another setup could give us a datetime string we did not anticipate. So using try/accept to catch these ValueErrors will also be important (we currently only catch KeyErrors i.e. the datetime field is not recorded). I think falling back to the file creation metadata, as we do in the current accept clause, is a good fallback here as well.

Here is a loose example that satisfies (1)--that is, if something goes wrong parsing the timestamp, the import will not fail. nothing yet done to wipe fractional seconds.

if (created := attrs.get("Date and Time", False)):
    try:
        created = time.strptime(created, "%a %b %d %H:%M:%S %Y")
        created = timestamp.TimeStamp(time.mktime(created)).RFC3339
    except:
        created = False
else:  # fall back to file creation time
    created = os.stat(filepath).st_mtime
    warnings.warn(
        f"{filepath.name}: could not import 'Date and Time' field: using file modified time instead"
    )
created = timestamp.TimeStamp(created).RFC3339