timezone missing from records returned by /devices/:macAddress

[mikepqr]

The /devices/:macAddress endpoint returns an array of json objects that each look like this:

{
  "dateutc": 1608940500000,
  "tempinf": 73.8,
  <...snip...>
  "loc": "ambient-prod-2020-52",
  "date": "2020-12-25T23:55:00.000Z"
}

The /devices end point returns an array containing objects that look like this:

[
  {
    "macAddress": <...snip...>
    "lastData": {
      "dateutc": 1609301160000,
      "tempinf": 72,
      <...snip...>
      "lastRain": "2020-12-29T08:46:00.000Z",
      "tz": "America/Los_Angeles",
      "date": "2020-12-30T04:06:00.000Z"
    },
    "info": {
      "name": "Foo",
      "coords": {
        "coords": {
          "lon": -123.456,
          "lat": 12.3456
        },
        "address": "Foo St",
        "location": "Foo City",
        "elevation": 50.000000,
        "geo": {
          "type": "Point",
          "coordinates": [
            -123.456,
            12.3456
          ]
        }
      }
    }
  }
]

There are a few inconsistencies here and I'd love to understand them better (and maybe get them fixed, if they're oversights).

• What is this property "loc": "ambient-prod-2020-52", which is included in the objects returned by /devices/:macAddress, but not in the objects returned by /devices?
• Why is "tz": "America/Los_Angeles" (for example) missing from the objects returned by /devices/:macAddress? IMO it should be included in each object, since each object has a timezone.

[Trasd]

I can confirm these results.

I added a String "loc" item to my record data (and removed it from the array object as is shown in the examples) and have had no problems.

As far as the timezone (tz), I would think that only the devices' MAC address lastdata array would need this information as record data is pulled via the MAC address. True, the MAC location can change, if the user moves or something, but it would seem overkill to put the timezone in each object.

Am I missing something obvious (like I often do)?

[mikepqr]

The timezone can be imputed from other information in the API and if that's what the user is supposed to do then that's fine (but it's worth documenting IMO). Agreed the object size overhead of adding, e.g. "tz": "America/Los_Angeles" to every object is not trivial.

But a simpler approach, which would also support stations that move timezones, would be to localize the date property on each record in the array to the timezone of the device, i.e. instead of

{
  "dateutc": 1608940500000,
  "tempinf": 73.8,
  <...snip...>
  "loc": "ambient-prod-2020-52",
  "date": "2020-12-25T23:55:00.000Z"
}

the objects could be

{
  "dateutc": 1608940500000,
  "tempinf": 73.8,
  <...snip...>
  "loc": "ambient-prod-2020-52",
  "date": "2020-12-25T15:55:00.000-08:00"
}

[Trasd]

I'm not arguing the merits of putting the timezone data into each record, I was just wondering why it was needed! If there is a valid reason, I'm all for it.

I think the API documentation (and the API itself) are in a state of flux. If you look at the apiary.apib file, you'll find the "device" output from our stations matches the devices'' "Event: subscribed" data format, (sans API key data?) which is supposed to be used for a real-time socket connection.

Could it just be a matter of the documentation not keeping pace with the programming?

[mikepqr]

Got it. In my case, the reason is that my weather station really did move from EST to PST. I know when this happened, so I can figure it out, but each of these records really does have a timezone associated with it, and that timezone potentially varies among the records, so IMO it makes sense to include it.

[owise1]

the observations you bring up are all byproducts of the way the data is handled internally. that is a good suggestion to include a localized date in the historical data. thanks.