Skip to content

Conversation

@melissalinkert
Copy link
Member

@melissalinkert melissalinkert commented Aug 12, 2025

This is one approach to fixing #40, but has not yet been tested on real data.
This is meant to fix the issue noted in #40, and subsequent issues on the same dataset.

With dateutil/dateutil#1252 still open, the %Y%m%d%H%M%S.%f%z format is not handled automatically. Separate cases for %Y%m%d%H%M%S.%f%z and %Y%m%d%H%M%S.%f appear to be necessary, as if I try a little test like this (using timestamps from #40 and #39 (comment)):

>>> new_date = "20241201163630.691045+0000"
>>> old_date = "20190612231659.000000"
>>> time_format = "%Y%m%d%H%M%S.%f%z"
>>> from datetime import datetime
>>> datetime.strptime(new_date, time_format)
datetime.datetime(2024, 12, 1, 16, 36, 30, 691045, tzinfo=datetime.timezone.utc)
>>> datetime.strptime(old_date, time_format)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Users\melissa\AppData\Local\Programs\Python\Python37\lib\_strptime.py", line 577, in _strptime_datetime
    tt, fraction, gmtoff_fraction = _strptime(data_string, format)
  File "C:\Users\melissa\AppData\Local\Programs\Python\Python37\lib\_strptime.py", line 359, in _strptime
    (data_string, format))
ValueError: time data '20190612231659.000000' does not match format '%Y%m%d%H%M%S.%f%z'

@sbesson sbesson requested a review from mabruce August 29, 2025 07:55
@mabruce mabruce linked an issue Aug 29, 2025 that may be closed by this pull request
@melissalinkert melissalinkert changed the title Add case for timestamps with timezone offset Newer scanner support Sep 12, 2025
Copy link
Member

@sbesson sbesson left a comment

Choose a reason for hiding this comment

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

A few inline questions but overall, the changes make sense from a code review perspective.

Does https://github.com/glencoesoftware/isyntax2raw?tab=readme-ov-file#areas-to-improve need to be updated to document the new expectations in terms of support?

Generally, are we close to dropping support for iSyntax SDK 1.x since support for the new scanners including the 16 to 8 bit filter will only be available in the iSyntax SDK 2.x if I understand?

@melissalinkert
Copy link
Member Author

Generally, are we close to dropping support for iSyntax SDK 1.x since support for the new scanners including the 16 to 8 bit filter will only be available in the iSyntax SDK 2.x if I understand?

Discussed a bit separately, but that's a little tricky. The changes here are meant to be specific to SDK v2, but we don't have a setup to test SDK v1 (nor are we likely to), so saying for sure that there is no impact on v1 use is difficult. I also wouldn't expect new scanner data to work with v1 at all. In the worst case, anyone who can't upgrade to v2 for whatever reason may need to stick with an older version of isyntax2raw.

Copy link

@mabruce mabruce left a comment

Choose a reason for hiding this comment

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

Works as expected on both an older and newer image, with and without --linear16to8.

@chris-allan chris-allan merged commit 6748a70 into glencoesoftware:master Sep 18, 2025
6 checks passed
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.

Timestamp in iSyntax not recognized

4 participants