Julien Papasian

> Unless specially checked, it would be better to use some other time (like noon?) so that 25h transition day still gives next weekday without doubling one. That would be...

I don't understand all the suggestions made in this conversation, they look terrible and require to put hacks on client-side instead of fixing the actual issue on server-side. All other...

> My app does not need any change either. You did make a change, you added 12 hours to each daily timestamp as a hack to be "safe". This is...

> I am using Unix timestamps and timezone auto. So I am expecting timestamps for GMT, which do not depend on any DST changes. That's not what `timezone=auto` means. Auto...

> "If format unixtime is selected, all time values are returned in UNIX epoch time in seconds. Please note that all timestamp are in GMT+0! For daily values with unix...

> Timezone auto + Unix format delivers GMT+0 timestamps and utc_offset_seconds No, timestamps are 00:00 local timezone, try by yourself: https://api.open-meteo.com/v1/forecast?latitude=35.6895&longitude=139.6917&daily=temperature_2m_max,temperature_2m_min&timeformat=unixtime&timezone=auto First timestamp is 1698764400, which can be converted to...

> Yes, the timestamp is 15h GMT+0 or UTC So, we agree, daily timestamp have never been 00:00 UTC when `timezone=auto`. However, they are if you use `timezone=GMT`. > applying...

> If `&timeformat=unixtime` is set, all timestamps are in GMT+0 Unless you also pass the `timezone` parameter. In which case, timestamps are returned in the given `timezone`, see first post....

> > Unless you also pass the timezone parameter. In which case, timestamps are returned in the given timezone, see first post. > > Unix timestamps are always in GMT+0....

> because in the first call returned values start at 00:00 at your location (auto) and in the second call they start at 00:00 in UK (GMT) Yes, that's what...