RFC: Epoch times

RFC: Epoch times

Postby Mimir » Fri Jul 15, 2016 11:51 am

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
Mimir
 
Posts: 3
Joined: Fri Jul 15, 2016 11:11 am

Re: RFC: Epoch times

Postby rkulagow » Wed Jul 27, 2016 8:38 pm

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.
rkulagow
SD Staff
 
Posts: 880
Joined: Tue Aug 14, 2007 3:15 pm

Re: RFC: Epoch times

Postby gtb » Mon Aug 15, 2016 1:40 pm

rkulagow wrote: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).
gtb
 
Posts: 58
Joined: Thu Oct 02, 2014 2:07 pm

Re: RFC: Epoch times

Postby Mimir » Tue Aug 16, 2016 7:12 am

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.
Mimir
 
Posts: 3
Joined: Fri Jul 15, 2016 11:11 am

Re: RFC: Epoch times

Postby gtb » Wed Aug 17, 2016 8:58 am

Mimir wrote: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
 
Posts: 58
Joined: Thu Oct 02, 2014 2:07 pm

Re: RFC: Epoch times

Postby gtb » Wed Aug 17, 2016 9:12 am

Mimir wrote: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?
gtb
 
Posts: 58
Joined: Thu Oct 02, 2014 2:07 pm


Return to Developer

Who is online

Users browsing this forum: No registered users and 1 guest