Date format: Unix timestamps?

[dbrgn]

Right now we're using ISO8601 format to specify a point-in-time in the GET parameters (e.g. "created_after").

Elm consistently uses unix timestamps to store datetimes and argues that while ISO8601 is good for formatting and representing dates (yes I know XKCD 1179) it's bad for data transfer:

• It requires parsing (which is overhead and can go wrong)
• There are multiple possible representations of the same point in time
• The UTC offset is useless if you don't know the timezone

For our use case, we want to filter based on a point-in-time, e.g. we want to get all measurements of the last 60 minutes. For this use case, the time zone is irrelevant and a normalized UTC timestamp actually makes things easier.

Therefore: Would it make sense to consistently use unix timestamps in the API?

(Low priority issue, maybe something for an API v2?)

[schmijos]

I like the idea of using unix time stamps in general. But I'm unsure if it should be used for historical temperature measurement data. Do we store this forever? Would we import historical data let's say from the year 1850?

[dbrgn]

Do we store this forever? Would we import historical data let's say from the year 1850?

Hm, I can't quite follow.

My reasoning is that when I have a measurement and want to get all measurements within 24hours after that, we have to do the following:

• Parse the datestring in the measurement
• Add something like a timedelta(hours=24) to the date using a datetime library
• Convert that back to a datestring
• Request the results in that range from the API
• Parse the datestring of every response
• Convert the parsed date to a user-friendly representation

With timestamps, we could do:

• Add 86400 to the measurement timestamp
• Request the results in that range from the API
• Convert the timestamps to a user-friendly representation

With time series, the absolute measurement time isn't even that important. The change over time and relative timespans (e.g. "3 days before now") are more important.

[dbrgn]

Would we import historical data let's say from the year 1850?

Definitely not. Seconds since 1970 UTC are a good specification for a point in time, we don't lose any information (but at the same time don't have to deal with time zones).