_get_data_mapper attempts to parse bytes as datetime even when it shouldn't

[ghost]

Reproducible example:

.query(
            """
            SELECT HASHBYTES('MD5', 'hello') AS hash
            """
 ).data

Error trace:

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
site-packages\pymssqlutils\databaseresult.py:48: in _get_data_mapper
    _parse_datetimeoffset_from_bytes(item)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

item = b']A@*\xbcK*v\xb9q\x9d\x91\x10\x17\xc5\x92'

    def _parse_datetimeoffset_from_bytes(item: bytes) -> datetime:
        # fix for certain versions of FreeTDS driver returning Datetimeoffset as bytes
        microseconds, days, tz, _ = struct.unpack("QIhH", item)
        return datetime(
>           1900, 1, 1, 0, 0, 0, tzinfo=timezone(timedelta(minutes=tz))
        ) + timedelta(days=days, minutes=tz, microseconds=microseconds / 10)
E       ValueError: offset must be a timedelta strictly between -timedelta(hours=24) and timedelta(hours=24), not datetime.timedelta(days=4, seconds=8640).

...\pymssqlutils\databaseresult.py:20: ValueError

[invokermain]

This is happening because the current code expects _parse_datetimeoffset_from_bytes(item) to raise a struct.error if its not a datetime, but I am guessing in this case the byte length matches the struct and therefore it errors when it tries to parse it as a datetime instead.

The fix for now is to add a catch for ValueError too but I don't believe this mitigates the whole issue as there is a chance that bytes will be parsed as datetime instead (very edge case) if it doesn't raise a value error.

The long-term fix will be to revisit if the original issue (datetime returned as bytes) is even applicable anymore with the restriction of pymssql >= 2.1.5, as the varies by TDS protocol version. This is a bigger issue I will revisit later.

[invokermain]

closed by #17, fix pushed in 0.1.5