[Bug]: Issue with Default session_start_time timezone in mock_NWBFile

[alessandratrapani]

What happened?

Description

A potential bug occurs when using a mock function for creating NWBFile objects. The function set session_start_time to datetime(1970, 1, 1, tzinfo=tzlocal()). This results in an OSError: [Errno 22] Invalid argument when attempting to write the file using pynwb.NWBHDF5IO. The issue seems to be caused by the interaction between tzlocal() and early datetime values (e.g., the epoch time 1970-01-01), particularly in systems located in time zones earlier than UTC, where the local time would fall outside the valid range for the epoch.

Steps to Reproduce

from pynwb.testing.mock.file import mock_NWBFile

# Create NWBFile object using default session_start_time 
# 
nwbfile = mock_NWBFile()

# Attempt to write the NWB file
with NWBHDF5IO('test.nwb', mode='w') as io:
    io.write(nwbfile)  # This triggers the error

Traceback

...
    return x.isoformat()  # method works for both date and datetime
..…\dateutil\tz\tz.py:291: in _naive_is_dst
    dstval = self._naive_is_dst(dt)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

self = tzlocal(), dt = datetime.datetime(1970, 1, 1, 0, 0, tzinfo=tzlocal())

    def _naive_is_dst(self, dt):
        timestamp = _datetime_to_timestamp(dt)
>       return time.localtime(timestamp + time.timezone).tm_isdst
E       OSError: [Errno 22] Invalid argument

Operating System

Windows

Python Executable

Conda

Python Version

3.11

Package Versions

No response

Code of Conduct

• I agree to follow this project's Code of Conduct
• Have you checked the Contributing document?
• Have you ensured this bug was not already reported?

[stephprince]

Thanks for pointing that out @alessandratrapani!

It looks like this may be a Windows specific error so I'm not able to reproduce locally, but if I understand correctly I think we should update the default session_start_time in mock_NWBFile to use anything later than datetime(1970, 1, 1, 12, tzinfo=tzutc()) to fix this issue.

[alessandratrapani]

I don't know if it is Windows specific, it seems to me it is "timezone" specific 😆, maybe that's why it is difficult to reproduce.
But simply passing a session_start_time of datetime(2000, 1, 1, tzinfo=UTC) did fix the issue on my side.