As far as I can tell MNE requires using UTC for meas_date. However, I want to keep the time of day information for my timezone. For example, if forced to use UTC then I need to add 5 hours to my datetime. That is a bit awkward since then I and others need to shift everything mentally or use some adhoc solution to appreciate the local time of day (this is sleep data and even sleep + wake data). The other solution is to use UTC but keep the local time. I don’t like that solution since that adds and perpetuates wrong information, possibly leading to major errors years from now. Is it true that meas_date has to be in UTC? Is there any work around? If I fork the code base and change this requirement, are there issues with other functions, etc.? Thanks
Hello,
Looking at the FIFF specification on which the MNE objects are based, the measurement date is stored as
meas_date 204 int32 uxtime "Measurement date (in Unix time encoding)"
There is a field related to the UTC offset:
utc_offset 159 string - "UTC offset of related meas_date (sHH:MM)"
which should allow you to specify a different timezone. I’m not sure it is properly used in MNE however, it looks like it is stored in info["utc_offset"] and that it is correctly written by write_meas_info, but it doesn’t seems to be loaded back by the reader.
I don’t think a fork to change a requirement is a good idea, as it might encourage you to stop updating your MNE fork from the main version that receives constant improvements and bugfixes. Instead, you could look into this utc_offset key, look if it’s correctly used in MNE, and propose changes in a PR to fix the issue. I think a change to .set_meas_date is required to correctly use this field.
Mathieu