manmatej
commented
6 months ago Yes, there is no way to specify time zone - by purpose. Doing so, we are trying to motivate users not to play with political time zones, as they can be biologically irrelevant and rather use UTC + calculate solar time from longitude. This is the best way how to synchronise photoperiod in case user will aggregate data. myClim strictly assume the time-series are in UTC. tz offset can be used to shift your time-series to UTC.
myClim was not designed as tool for time zones conversions, there are other packages which can be helpful.
DST is a big issue in logger time-series in general. User needs to be careful about this and there is no easy way how to solve this automatically. Many loggers are synchronising their internal clock with PC so you can have e.g. summer time. With the summer time you set up and deploy the loggers in the field then after half year a you download the data, but your PC is in that time in winter time. What would be the logger series time? What would the logger do on the DST switch? Will there be missing one hour? duplicated one hour of measurements? Who knows.
This is hardware specific. Our experience with several logger types showed completely different behaviour manufacturer by manufacturer even logger type by logger type.
So the answer is - DST must be solved before import to myClim by well informed user who know the behaviour of his/her loggers. Unfortunately, we do not see any safe method how to help users with this issue within the myClim.
In the mc_read_data() function there's no way to specify the timezone of the data . There's, however, a tz_offset parameter which it isn't exactly the same (think about Daylight Saving Time). Furthermore, it says that it's "not used for TMS", but I tested it out for them and it indeed shifts the datetime.
I think a tz parameter could be added and the tz_offset removed unless there's a user case I don't know of.