[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.

[h-mayorquin]

Are there downsides to using the machine time and timezone when using the mock?

[alessandratrapani]

Are there downsides to using the machine time and timezone when using the mock?

I don't see any issues

[bendichter]

@alessandratrapani does datetime.datetime(1970, 1, 1, 0, 0, tzinfo=UTC) work?

I have a slight preference for keeping the 1970, since it is clearly filler data and won't be mistaken for real data. If that doesn't work, we can use the current time.

[alessandratrapani]

@alessandratrapani does datetime.datetime(1970, 1, 1, 0, 0, tzinfo=UTC) work?

I have a slight preference for keeping the 1970, since it is clearly filler data and won't be mistaken for real data. If that doesn't work, we can use the current time.

Yes, it is working