How can we help?


Timzone issues in custom parser

Comments

10 comments

  • Avatar
    RainMachine Nicholas

    Yes it's an issue with graphing library on web interface.

    0
    Comment actions Permalink
  • Avatar
    Matt Ahlgren

    Nicholas can you please confirm if the data added with addValue should use a UTC or local timestamp? As George mentioned above I've been adding it with UTC timestamps but the the data I get back from /parser/{uid}/data doesn't seem right. Eg:

    I add the forecast for 2019-02-03 using UTC timestamp 2019-02-02 13:00:00Z (which is 2019-02-03 00:00:00 local). The API shows this:

    "day": "2019-02-02 00:00:00",
    "hourlyValues": [
      {
        "hour": "2019-02-02 13:00:00",
        "temperature": null,
        "minTemperature": 23,
        "maxTemperature": 37,
    ...

    I.e. the "hour" is correct (if that's UTC) but the "day" is wrong even in UTC.

    0
    Comment actions Permalink
  • Avatar
    Matt Ahlgren

    Ok I guess the "day" above is just a bin, but after looking at the parser and mixer output from the API something still isn't right.

    The mixer output for the above is:

    {
      "day": "2019-02-02 00:00:00",
      ...
      "minTemp": 23,
      "maxTemp": 37,
    ...

    I.e. there is no "hour" entry in the mixer so regardless of if the above "day" stamp is taken as UTC or local it's wrong. 37 is the forecast for 2019-02-03 so if "day" in the mixer is UTC then it's 13 hours behind and if it's local it's 24 hours behind.

    What's going on here?

    0
    Comment actions Permalink
  • Avatar
    RainMachine Nicholas

    Day will always default to 00:00 the only information taken by RainMachine and UI is the day date not hour. Mixer will only work with aggregated day values. Parsers might have hourly values but mixer only day aggregated from all parsers and all hours.

    0
    Comment actions Permalink
  • Avatar
    Matt Ahlgren

    Thanks Nicholas, but it appears the mixer is taking the wrong day value. 2019-02-02 13:00:00 UTC is not the forecast for 2019-02-02, it's the forecast for 2019-02-03 (local time). It looks like the mixer is working with UTC days by mistake somewhere.

    Truncating the datetime object to 00:00 would work for negative timezones such as North America but not positive time zones.

    0
    Comment actions Permalink
  • Avatar
    RainMachine Nicholas

    So you are using rmCurrentTimestamp() function to add data and when you get the data using the API test page (not Web UI) you are seeing data being shifted a day back ?

    What is your timezone ?

    0
    Comment actions Permalink
  • Avatar
    Matt Ahlgren

    I'm not using rmCurrentTimestamp() no. The timestamp used to add the data is the timestamp of the data from the BoM xml feed (E.g. 2019-02-02 13:00:00 UTC). Then yes when I get the mixer data from the API (using Postman) it's showing 2019-02-02 00:00:00 (which appears to be UTC) when it should be 2019-02-03 00:00:00.

    My current timezone is +11 (in DST at the moment).

    0
    Comment actions Permalink
  • Avatar
    RainMachine Nicholas

    The current beta update includes these fixes:

    1. The Web UI should now properly render weather service graphs to local device date/time

    2. Uploading custom weather service parsers from Windows 

     

    The RainMachine Mixer saves data in device local time hour 00:00 as a unix timestamp.

    0
    Comment actions Permalink
  • Avatar
    Sam Morrison

    I think I'm seeing this bug with the web UI and timezones, I'm running Web UI 1.13 with firmware 4.0.1131. Should I expect this bug to be fixed in this release?

     

    0
    Comment actions Permalink
  • Avatar
    Matt Comer

    I am seeing this problem with 4.0.1122 and WebUI 1.13. The post from Nicholas about the fix was back on April 04 so I was expecting that this was fixed by now?

    To be specific, data from the wf-parser.py (WeatherFlow parser) appears to be shifted +4 hours for me in the graphs.

     

    Matt

    0
    Comment actions Permalink

Please sign in to leave a comment.