The documentation could mention what the epoch of the timestamp is too, please?
When I've figured that out I'll try to work out whether a "login" is a username/password exchange (guess not, as I like I imagine most users allow my browser to store a cookie for months on end).
I think the epoch is the Unix/Linux Epoch: 1970-01-01.
This looks reasonable, anyway:
$ perl -e 'print scalar(localtime(1512275876)), "\n"'
Sun Dec 3 15:37:56 2017
Or at least mostly reasonable: it's about 17:37 now actually, but perhaps I've been "logged in" for two hours? (Not having multiple accounts it's hard to see what the green square is doing, and I'm accessing the site intermittently, hunting cheats as usual. 
)
Now and then I play some chess, too. That's more fun but I'm also watching the cricket.
The documentation could mention what the epoch of the timestamp is too, please?
When I've figured that out I'll try to work out whether a "login" is a username/password exchange (guess not, as I like I imagine most users allow my browser to store a cookie for months on end).
Unix as far as I understood.
As far as I can see, the current available attributes for the profile endpoint only tracks a 'username/password exchange'. The `last_online` attribute only updates after a user signs back in.
I'm currently accessing the site from three browsers using two different IP addresses.
Earlier this afternoon I did temporarily have a third browser running; maybe that was the "login" event although it was automatic via a cookie.
I think the epoch is the Unix/Linux Epoch: 1970-01-01.
That sounds about right :-)
I'm currently accessing the site from three browsers using two different IP addresses.
Earlier this afternoon I did temporarily have a third browser running; maybe that was the "login" event although it was automatic via a cookie.
Interesting. I have not tested it out using other browsers.
We've got a few years before we have to worry if that Integer is a 32 bit or 64 bit quantity then ... but 64 bit would be best.
(Maybe the 32/64 bit thing is obvious to someone who knows more about JSON than I do. I looked at the https://api.chess.com/context/Player.jsonld and it said "Integer" via schema.org.)
We'll look into more "current" data. This API has few rate limits and no authentication because it is highly cached, and so data that change frequently like that can be problematic. We might make it a separate endpoint, if that works for you.
Due to the data we collect, we would not be able to produce historical data like "when was the last time this person was in live chess," but current data of "this person is/is not online, in live chess" (same as the avatar pip) should be doable with a 5-minute resolution.
How does that sound?
We'll look into more "current" data. This API has few rate limits and no authentication because it is highly cached, and so data that change frequently like that can be problematic. We might make it a separate endpoint, if that works for you.
Due to the data we collect, we would not be able to produce historical data like "when was the last time this person was in live chess," but current data of "this person is/is not online, in live chess" (same as the avatar pip) should be doable with a 5-minute resolution.
How does that sound?
That sounds like a nice solution. It would be great to have it as 'current' as possible. I have a use case nearly finished -at least as a prototype. I just was surprised when the 'last_online' attribute did not provide what I originally thought it did.
Something like "when was the last time this person was in live chess," was what I had in mind overall. It was more along the line "When was this person last online,". But if you could provide the current data of "this person is/is not online, in live chess", then I could just request the attribute and give a timestamp from my end.
Five minute resolution is finer than I can imagine wanting, currently.
I will -- when the match endpoint is ready -- write a report that will list the most recent match every (or any individual) club member played in.
I very much want to extend that to "signed up for a vote chess game" and ideally "voted in a vote chess game" but understand that each endpoint requires design, implementation and testing, and the active vote chess players within a team are fairly readily identified manually, so there's no big rush for that data.
If live matches and/or tournaments become popular, then they're also club activity I'd like to be able to report.
Essentially my report will be focussed on the negative:
(*) Expulsion would in most teams be simply kicking the player out. If they return to the site -- or ask to return to the team -- fine. For a few (the suspected cheats, abusive members who don't meet chess.com's criteria for abuse, members who always rase hackles of opposing teams) a request to rejoin might be declined.
Online status as a separate endpoint is now available: https://www.chess.com/news/view/published-data-api#pubapi-endpoint-player-is-online
Thanks, I guess. (I guess because right now I have no use for it, but maybe one day ...)
We now have three time-on-site related items about members active on the site:
Looking at my own last_online value where I was inactive for several hours, then came online without a password exchange:
$ date -u
Fri 9 Feb 2018 15:19:52 UTC
https://api.chess.com/pub/player/skelos
"last_online":1518189027
$ perl -e 'print scalar(gmtime(1518189027)), "\n"'
Fri Feb 9 15:10:27 2018
That looks pretty good. I might only have been online ten minutes as I'm not through my notifications yet, and have only posted (other than this item) in one vote chess game. I would have thought I'd been online more than ten minutes, but perhaps something I did (posting in the vote chess game?) triggered an update.
It would be nice if the Profile endpoint would provide information as to the status of a user. For example whether they are 'online', in 'live', or have not been on for a few hours.
Maybe the existing `last_online` could also be changed so as to show the actual time the user was last online / active on the site instead of the last log in -i.e after actually logging out of the site.
Perhaps a new `last_active` attribute could be added to support this and the `last_online` attribute be renamed to `last_login`. Plus an attribute for showing whether the player is just online or in live as well.