RFC: Epoch times

[Mimir]

AIUI SD-JSON sends all times as "datetime" in ISO8601 'combined' format, normalised to UTC.
e.g.
"datetime": "2015-07-15T18:30:00Z"

Generally speaking, any program using this datum will want to either (i) select programmes using a date/time range and/or (ii) display the time in local format (+ local TZ). To achieve either of these, the program will probably initially convert the "datetime" to epoch-seconds before performing range checking and/or re-converting for output.

I suggest it would simplify matters for programs using the SD-JSON feed if that feed also included the time in epoch-seconds.
e.g.
"datetime":"2015-07-15T18:30:00Z"
"unixtime":1468607400


If stored in SD database, this has the advantage that the conversion need only be done once (in SD) rather than every time a program accesses the data item (think multiple users independently running the same program on the same data). Two benefits would accrue: faster processing time in the using program, and less chance of conversion error (when a standard library is not used).

Geoff

[rkulagow]

No comments from other developers? This is a fairly simple add and won't break backward compatibility as it would be a new field, so if you application isn't looking for "epochTime" then Nothing Happens.

[gtb]

No comments from other developers?

Personally I see no reason to have the time twice, but I certainly do not care a lot one way or the other (other than the philosophical approach that having two things representing the same thing will eventually lead to confusion. If one needs a faster conversion from ISO8601 to something else, write it in a native language, or a use one of the "approximate" conversion routines that ignore a bunch of the complexity for speed). But as I said, I do not care a lot one way or the other as long as if SD implements it I expect it to be time accurate (i.e. not one of the quicker "approximate" converters).

[Mimir]

I wouldn't say "eventually" (as in it's inevitable) as there's no evidence of that. Proponents of FNF dbs often claim it causes problems, but IMO rarely seen in practice.

Sure one could write a customised routine in a low-level language to handle the datetime, but that's missing my point. Since, ISTM, every program which accesses the JSON feed will want to convert the datetime to a local TZ and/or search for a range of schedule times, then I think any parsing of a textual datetime is wasteful.

Ordinarily I would suggest just storing unixtime, however to maintain backwards compatability it should also keep existing datetime.

[gtb]

Since, ISTM, every program which accesses the JSON feed will want to convert the datetime to a local TZ

Demonstrably false. I do everything in UTC. Now, perhaps you meant *you* need local time. That is not the same as *every*.

[gtb]

Sure one could write a customised routine in a low-level language to handle the datetime, but that's missing my point.

Actually, I do not think it is. Almost every language has date/time conversion functions. Why would you not want to use them?