Investigate why the hours are in UTC for East Coast locations

[JulianNorton]

What's the current situation?

Times are not correct

"Tomorrow" threshold is on UTC time instead of local time

What do you recommend?

Look into the partial that is breaking up today/tomorrow weather and see if that can be done with local time instead of UTC time.

[ivanfrias]

can I take this?

[JulianNorton]

Please do @ivanfrias ! Let me know if you need any help.

[ivanfrias]

will do, can you assign it to me , please ?

[ivanfrias]

@JulianNorton moment.unix() converts to a local time. I am based on GTM so it seems to be working fine for me. Is there a better way to verify this behavior? I noticed that at the top the position is set to nyc by default. Maybe we should parse the unix timestamp to the selected position

[JulianNorton]

@ivanfrias I've had success testing this before via Tor or VPN (to change my location).

I've verified it myself now by looking at New York – it says tomorrow is in 2 hours.

I'm not sure where moment.unix() gets it's local time – it's worth looking at the package perhaps?

https://stackoverflow.com/questions/32540667/moment-js-utc-to-local-time

[ivanfrias]

@JulianNorton OK, I am connected via VPN to US server.

Still, the position doesn't seem to change:

Is there any additional setup I need to do ?

Thx!

[JulianNorton]

Apologies for the trouble but I can reverify tomorrow in the AM in a local setup. It’s driving me crazy so I very much appreciated you reaching out to help. If you have any ideas let me know!

On Oct 1, 2019, at 5:53 PM, Ivan notifications@github.com wrote:

 @JulianNorton OK, I am connected via VPN to US server.

Still, the position doesn't seem to change:

Is there any additional setup I need to do ?

Thx!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[JulianNorton]

Hi @ivanfrias I'm having a hard time replicating this because it's too early! Once it's closer to midnight UTC I'll post another screenshot.

[JulianNorton]

Okay so on localhost it seems like the time is fine! I wonder if this has to do with the server time. Any advice @ivanfrias?

[ivanfrias]

Hey @JulianNorton, it could be. If the google lib fails to get the right timezone of the inbound IP, then undefined is set as the default timezone of moment. If the server is in UTC, then all remaining date/calculations will be based on that.

If there was no 'Change Position' feature we could parse the date on the client side which would use the browser timezone. Locally, the request to get the timezone is blocked because I don't have a GOOGLE_API_KEY. So my question is: how can I get one? Clicking on the link of the ticket ( on the instructions) will take me to Google APIs page but It keeps spinning.

[ivanfrias]

Interesting: I found that the key is actually commented. Any reason for that ?

 this.setTimeZone = () => {
    return timezone({
      // key: process.env.GOOGLE_API_KEY,
      location: req.params.latitude + ',' + req.params.longitude,
    })
      .then(res => {
        req.params.tz = res.timeZoneId;
        moment.tz.setDefault(req.params.tz);
      });
  };

[JulianNorton]

https://github.com/JulianNorton/weather-10kb-wxkb/commit/7a45fe780f44785ce9090139232652a20358bc64 I'm not quite sure why, but in that commit I was removing things like 8pm or 4pm so it would say x hours from now. I can try uncommenting that out locally tomorrow and see what it does!

[JulianNorton]

When I uncomment that line I get the following error:

I believe that's why it's commented out

Julian

[JulianNorton]

[ivanfrias]

hey @JulianNorton, this is an SSL error coming from the google-timezone-api which flags the 'key' as optional but it is not, at least not today, it may have been optional before. Passing a google key doesn't help, as the response is denied on the back-end.

I'll try troubleshooting the lib tonight.