Closed basilfx closed 8 years ago
I'll take a look at this over the weekend. As far as getting rid of _ts2milli, I'd much rather fix it. I'd rather not adhere to Java's "everything in milliseconds" bullshit. It's an anti-convention and I'd rather have an API that adhere's to actual conventions rather than stupid, made up crap like Java does. I will gladly fix issues, but never in a million years will I go the lazy route of just using the Java "convention". Unix time is number of seconds since the epoch, not milliseconds since the epoch.
basilfx: I want to make it clear that I do appreciate your raising of this issue, and none of the vehemence in that previous comment is directed at you in any way. I just really hate Java.
Thanks for looking into this :-)
basilfx: I've got a fix in, currently on the subs_53 branch, that just translates the return value to a proper unix timestamp. Feel free to grab that branch and play with it if you would like. It's lumped in with some API updates to correspond with the subsonic 5.3 release. Once I get the rest of the changes tested, I'll roll all this into master and do a proper release.
When I request the index using
getIndexes
, I get a response withlastModified
isX
(whereX
is time in milliseconds). When I querygetIndexes
again usingifModifiedSince
set toX - 1
, I don't get a result, but I would expect the same response becauseX - 1
is a timestamp in the past.Now I understand that this problem is because
ifModifiedSince
is translated using this method, but that is inconsistent with the API, which requires theifModifiedSince
parameter to be in milliseconds.I would suggest to remove the
_ts2milli
method.