Timezone for /get_user_recent seems off

[knht]

I'm currently facing the problem that the timezone seems to be off by exactly 2 hours early.

I usually don't care about the UTC+8 stuff and fully understand that it's huge hassle to change everything to timestamps looking at an earlier issue from 2014, but now the time seems to be off by 2 hours.

Converting the timezone to UTC according to the ISO standard in JavaScript:

const scoreDate = userRecentResults[0].date; //2018-09-27 03:30:18
const timeStampPlay = new Date(scoreDate).toISOString(); //2018-09-27T01:30:18.000Z

Which results in following UTC time: 2018-09-27T01:30:18.000Z which is exactly as stated before 2 hours off, because this score was made at 2018-09-27T03:30:18.000Z UTC.

Usually I'd think it's been UTC since the beginning and everything is fine that way, but without changing any code on my side this shift in time happened tonight resulting in wrong Discord embed timestamps.

I'd love to hear back as soon as possible! Thanks in advance.

[peppy]

Thanks for reporting this. It's likely due to a migration to new infrastruture I'm currently performing. I'll report back soon.

[peppy]

Out of curiosity, is your local time zone (the system you're running this code on) UTC+2?

I believe the API is now returning the correct UTC time but without the "Z" prefix so your conversion is treating it as a "local" time zone.

[omkelderman]

fwiw I convert my dates in javascript (nodejs) like this:

// something somewhere out of the API, a "mysql datetime string"
var apiDateStr = '2018-09-27 03:30:18';

// manually changing the string so it is a valid ISO string with correct timezone info from api
// replace the space with a T, and add '+8:00' so it becomes 2018-09-27T03:30:18+08:00
var isoApiDateStr = apiDateStr.replace(' ', 'T')+'+08:00';

// the javascript date constructor now has all the info needed
var date = new Date(isoApiDateStr);

// im in UTC+2 atm
console.log(date.toISOString()); // 2018-09-26T19:30:18.000Z
console.log(date.toString()); // Wed Sep 26 2018 21:30:18 GMT+0200 (W. Europe Daylight Time)

[peppy]

As I mentioned above, the +0800 is likely gone now and all dates should be being returned as UTC.

[omkelderman]

all dates across all endpoints everywhere? Shall I edit the docs then to change all mentions of +8 to UTC?

also guess #52 can be closed then as well right?

[peppy]

Yes, hopefully. Please confirm this is the case first.

[omkelderman]

ive walked through all the endpoints and looked at every place a date is used, from what I can see every date I come across (including get_user_recent what this issue was originally about) is in UTC. I'll change this in the documentation when I get around doing that (unless someone is faster XD)

Little sidenote, for most tests I compared the date to what I see on the website, which shows hovers with a explicit UTC notice, so I guess its fine, but it is obviously the same datasource, so maybe if a migration issue caused things to be weird, then maybe it is wrong on the website itself as well? I did check a few things (like score set) with the time I have locally in my client and that seem to match up, so I guess its fine.

little feature request from me: transform the string to a xxxx-xx-xxTxx:xx:xxZ type of string so there is no doubt whatsoever its a UTC string, and I can pass it as is to any date constructor in just about any language and not have to worry about timezones n stuff. Not sure if this would be a too big (probably breaking) change tho :thinking:

[knht]

Thank you guys very much for addressing this issue so incredibly fast! Also just checked all endpoints and wrote a new test and all dates are now in UTC with correct Discord Embed Timestamps!

const utcDate = userRecentResults[0].date.replace(' ', 'T') + '.000Z';

[omkelderman]

@peppy I asume the since param in get_beatmaps is UTC as well now right?

[peppy]

Yes, all parameters should be.

[hker9527]

I can confirm that this issue still affects now. My case the returned date has become UTC-8. The left one was fetched from another portal: https://osu.ppy.sh/beatmaps/%B_ID%/scores?type=global&mode=osu, while the left was fetched from the portal provided in this API documentation.