Hourly time is offset by 30 minutes in certain locations

[guillaume]

# mumbai Asia/Kolkata timezone does not return hourly time for requested time 
# offset is 5.5
% curl -s "https://api.pirateweather.net/forecast/<REDACTED>/19.0785451,72.878176,1678732200?&units=si&extend=hourly&tz=precise" | jq '.hourly.data[0].time'
1678730400

# Usually that will return the time requested
# offset is -4 for "America/Toronto"
% curl -s "https://api.pirateweather.net/forecast/<REDACTED>/40.7127281,-74.0060152,1678680000?&units=si&extend=hourly&tz=precise" | jq '.hourly.data[0].time'
1678680000

[github-actions]

There has been no activity on this issue for ninety days and unless you comment on the issue it will automatically close in seven days.

[cloneofghosts]

Looks like this issue was missed but I tested and I can confirm that for fractional timezones the time parameter is not aligned with the top of the hour but the daily block works fine.

A city to test this with is St. John's, Newfoundland (47.486771,-52.751787) but you have to use tz=precise to demonstrate the issue otherwise the timezone is completely incorrect.

  "latitude": 47.486771,
  "longitude": -52.751787,
  "timezone": "Etc/GMT+4",
  "offset": -4.0,

VS

  "latitude": 47.486771,
  "longitude": -52.751787,
  "timezone": "America/St_Johns",
  "offset": -2.5,

I'll tag @alexander0042 so he can look into this. #74 seems to be a related issue to this one but was only fixed for time machine data.

[github-actions]

There has not been any activity on this issue in the last ninety and will automatically close in seven days. Comment on this issue to prevent this issue from closing automatically.

[cloneofghosts]

Will bump this one last time. @alexander0042 maybe this can be sorted for the 2.0 release?

[alexander0042]

Yup! Thanks for the bump. I've tagged it to keep it alive,

Just to clarify here- is the issue that these locations always return the incorrect hourly times, or only when specific times are requested?

[cloneofghosts]

I believe this was already fixed in the TimeMachine but when I request data for St. John's, Newfroundland all the times in the hourly block are off by 30m. The daily block returns the correct time so it's just something with the hourly section which isn't working correctly.

I did a test query and the first block in the hourly section shows "time": 1697144400, and converting that into a proper timestamp you get:

1697144400 converts to Thursday October 12, 2023 18:30:00 (pm) in time zone America/St Johns (NDT)

Here's the URL I used to call the API https://api.pirateweather.net/forecast/API/47.486771,-52.751787?units=ca&tz=precise. I'm sure other places with 15/45 minute time zones are off by the same amount.

[alexander0042]

The classic Gander issue! Fixed this in 2.0i along with my other timezone bugs

[cloneofghosts]

Did a quick test and can confirm that this is fixed so will close this issue.