Currently we do this: we create all timestamps for ics file export in UTC and let the tool that imports the ics file set the local timezone. This led me to conclude that we don't have to know the users timezone when creating the sunrise events etc. So we removed the timezone argument from the suncal ics routine completely (and just use UTC for all internal calculations)
I might be confused, but I think that procedure is not 100% right. If someone wants to know the sunrise for a particular day, say the 13th of March, they are thinking about a sunrise between 13.3.2023 0:00 and 13.3.2023 23:59 in their local time zone. But we are then searching for the sunrise between 13.3.2023 0:00 and 13.3.2023 23:59 in UTC. The difference between the two time intervals can be drastic and lead to wrong results, right?
@twitzelbos @gbordyugov Do you agree that we have to bring back the timezone argument to suncal ics?
Currently we do this: we create all timestamps for ics file export in UTC and let the tool that imports the ics file set the local timezone. This led me to conclude that we don't have to know the users timezone when creating the sunrise events etc. So we removed the timezone argument from the
suncal ics
routine completely (and just use UTC for all internal calculations)I might be confused, but I think that procedure is not 100% right. If someone wants to know the sunrise for a particular day, say the 13th of March, they are thinking about a sunrise between 13.3.2023 0:00 and 13.3.2023 23:59 in their local time zone. But we are then searching for the sunrise between 13.3.2023 0:00 and 13.3.2023 23:59 in UTC. The difference between the two time intervals can be drastic and lead to wrong results, right?
@twitzelbos @gbordyugov Do you agree that we have to bring back the timezone argument to
suncal ics
?