Some birthdays are inaccurate

[lucky-swede]

According to jomo's creation date finder which I believe was implemented into this API (or something similar was implemented), January 10th, 2010 is the earliest date where accounts can be created. The user "Mixo" (https://api.ashcon.app/mojang/v2/user/Mixo) returns a creation date in 2009 when it shouldn't be returning one. Plus, the user is legacy, and legacy users can't have their creation dates tracked via the API. If you use Jomo's gist and tweak it to go back to even January 1st of 2008, or even before that, instead of January 10th of 2010 (when the API first started recording creation dates - I own an account that was "made" on this date, that's how I know), it'll still say the account is created before then, which is impossible. For most legacy accounts this API returns null as the created_at value, but for whatever reason this isn't the case for Mixo as well as a few other legacy accounts that I've noticed:

unmigrated:c5effe56fab6404b8fdace47b82e7b8d:beside:2009-09-13
migrated:f9a707d93d94433fb06637f676763876:Blogs:2009-05-17
migrated:9c936f53bced46a4b91303bac2bf4e49:Castors:2009-07-14
migrated:b0546dc1dcea4eacac08aa1ddd646de6:Cathy:2009-05-24
migrated:a288919892404b769f35608315a29ef9:Charm:2009-06-23
unmigrated:5e21c3c8c18a430f9dd3e5f4db209cbd:Codfish:2009-12-24
unmigrated:e1355349a2a442e2ae11180ef37d1800:Conf:2009-11-23
unmigrated:5b63210e6a054999a68e56145ad37f4a:corkscrew:2009-06-30
migrated:1f0f8699b4894839971aa3dd97ce39e2:Countess:2009-05-29
migrated:59ee23c1d5d04963a630f7893b5d296a:Creation:2009-09-13
unmigrated:0d95fd9b96de4a2e88736b4086eaab0b:Deluxe:2009-08-17
unmigrated:39487a3e882b4174a6e8216f67c3181a:Desideratum:2009-05-17
migrated:03eeb16d6f094fd4a5ceb865c5a1ce44:Digs:2009-05-30
unmigrated:7382a78d02f040cf8e599538feb7c2b2:DURATIOn:2009-05-18
migrated:520d0b4a0a51497b89477665dcf1b627:elbe:2009-07-22
unmigrated:22a7283ae5a949e5af59e0a5bfbd683f:Emancipation:2009-10-13
unmigrated:7725a3d1c5f64371980169428dd97d14:Flanks:2009-07-02
unmigrated:8cc659c6daf24cc1b60117f09a528c93:Fleet:2009-05-24
unmigrated:4cf1b6fb2a3645cab530b6da6cb9cf56:Frenzies:2009-11-20
migrated:1dfada6c1a0741769e5e031ecf4d343d:Grandparent:2009-05-25
unmigrated:6aff514d261c4f9c9312915d11b4df02:Guerilla:2009-07-15
unmigrated:ba92b3be33bc4d708382abe3d65b7d21:Heir:2009-05-24
unmigrated:44a3ca869c204777853f0dcc21d32cb7:Hydrostatic:2009-05-18
migrated:10043336edc24a98847af1e51ceb51a1:Impulsive:2009-05-20:MINECON 2013
unmigrated:e5de7dfda1044bcaad8105aa2181acb6:InLaw:2009-09-19
migrated:9b99751ffda04c0e879307ad4e7e95ed:Jog:2009-05-20:MINECON 2016
unmigrated:0dd724f4820b4f27a46a1a85ed0da26f:leafy:2009-12-12
migrated:130a746198cb4d2e85c41639a159e716:LLP:2009-05-31
unmigrated:c9512774e9fc493aa9607d053a40be1d:Lye:2009-09-09
unmigrated:2167e69534434a919c191b2aaea65cb0:medicaid:2009-05-23
unmigrated:2111b59b7c6e4f38a64c30b7d0d8e39d:Morphological:2009-05-24
unmigrated:1329970632d8497fb8e48e8e7acba20b:Narcissism:2009-07-15
unmigrated:2343ad37ba9c4696aea461f0f71f9400:Obstreperous:2009-06-08
migrated:38039d30a7794047b28038b3f83a9a2d:Oxcart:2009-07-08
unmigrated:fc380f67657045baa3623b493391cf26:Parson:2009-12-03
migrated:037c4cf1518d4e30b3dcd11f254f7dfe:Pay:2009-06-15
unmigrated:2ca98bf8ec71448982bd756d72140060:pdas:2009-09-26
unmigrated:e7209c20833c44c9b2d5fd0d7d3a6021:Principality:2009-09-13
migrated:53f7d1ae8331490196e2f3343d71e393:Quarrels:2009-10-10
migrated:b5d4d28aa90a43d5a3edf2256a306206:raincloud:2009-08-13
unmigrated:91615e05a5fe4e08a228987540b7f92d:Reckoner:2009-05-23
unmigrated:b5a2d3c41a5f43d08cd8ca16b8ff7a07:RobEd:2009-06-01
migrated:86fb930fac3e4cfe97366f5eb85c4df5:Sahib:2009-06-01
migrated:e17249d005d6455dbea593abbed01a34:Scabies:2009-05-17
migrated:d2b365fcb13e429789ba10b733219b0c:Seismic:2009-06-15
unmigrated:fabee1a1968a42c99981ff115f0d2d6e:Severally:2009-05-21
unmigrated:8a9c4c2a7e7341f1b51125147d4fef68:somali:2009-05-20
unmigrated:31f0f7698e0f4c57abd552623ea3c04a:Supine:2009-06-16
migrated:5800b1578ce44896b002a09008d0fdf4:Surreality:2009-08-21
migrated:b6a4071b07eb40d9994f3cf40444bc8d:Surround:2009-05-20
migrated:8177f7377dfb4dbb870f892be12b956d:Tatty:2009-09-12
unmigrated:dc4a9a043a8947b3923d780002f5dae3:therapy:2009-05-31
migrated:896c1c6508f14d109dc94ff45cd3dfd6:Tossed:2009-05-19
unmigrated:a07996011b1b4e11aff83ed8c2af1f69:waspish:2009-05-25
unmigrated:23715781e8fd4b59b0ad2e359d2ef5dc:woebegone:2009-05-31
unmigrated:d02df899f3d94eff92629f55f29b4db4:Woken:2009-12-15
migrated:8ca5a4593c1e42029ac494a29cedb1fd:woodland:2009-05-18
unmigrated:ec4adc1220ee4efcbba7d8286fe3f64c:wordy:2009-07-15

Caching creation dates that are null is, at least in my opinion, a bad idea - if the user migrates at a later date, the date returned will still be null.

Also, using this API you should be able to see whether a user is legacy/unmigrated or not, this feature should be added soon especially considering the MS migration.

The API also returns incorrect naming histories for accounts I have noticed, for example the user 0d565263382f433687eb45c9c6375eff with a name history of 23 names only had their current name in the history according to this API. ([{'username': 'myeve____'}]) This issue has since fixed itself, and I presume it to be a ratelimit issue, but if this API is ratelimited from any Mojang endpoints it should return 429 to avoid returning incorrect API responses, at least in my opinion.

[Electroid]

Thanks for flagging this, yes the caching will need to be adjusted. I do plan on issuing an update soon, especially with the Microsoft migration around the corner.

[lucky-swede]

Any ETA on when? Hoping soon considering I have a lot of UUIDs I’d like to pass through to the API

[lucky-swede]

Quick update to this case.

The method that is used to fetch creation date has stopped working (see https://bugs.mojang.com/browse/WEB-3367 for more information).

It was stated that the caching will need to be adjusted. Is it possible for you to avoid adjusting the cache for most accounts, as they are no longer able to be re-grabbed from the API, only removing creation dates for accounts "created" in 2009? Those creation dates should be null but for some e.g Jog then there was a way to fetch the dates for these (we call them giftcoded accounts/giftcode snipes) - if you'd like to see what we used to do (again sadly not possible anymore), you can check 88/mcreation.

Also, just out of curiosity - how many accounts are in the API's cache currently?

[Electroid]

Thanks for linking that issue. That's concerning, I hope they fix it!

I might punt a v3 because I'm assuming Microsoft/Mojang may change the API. Although, I am considering just adding the legacy tag for v2 in the mean time.

There are millions of "birthdays", I can look at invalidating the impossible dates this weekend.

[lucky-swede]

Hoping they fix it too.

Please do add the legacy/demo tag for v2 while we wait for the new API. Would be very useful, and I don’t think it’s too hard? Hit /user/profile/ I think... and that’s it. You can use the session server endpoint with just legacy but the demo tag is helpful as well.

The impossible dates are anything in 2009. 2010 January 10 isn’t impossible just to clarify.

Also how many accounts do you have cached currently?

[Electroid]

I just deployed legacy and demo fields. If either of those is true, created_at will be null. So I think that solves most of these edge cases.

Going to keep this open until Mojang fixes the other issue.

[lucky-swede]

Thank you, much appreciated :)

Seems as though demo field isn't working - https://api.mojang.com/user/profile/ba91e614adff4a4483482e52953677b0 shows demo: true, but the API isn't... https://api.ashcon.app/mojang/v2/user/ba91e614adff4a4483482e52953677b0

A friend of mine also said to let you know to make sure not to cache legacy/demo status as this can change.

Any chance we can get invalid username support as well? I have users like Mr.LoL, crazybitingturtle, and glenn-stroek in my database and would like to see records for them via the API. Should be an easy regex change from just looking at where username validation takes place in this code?

[lucky-swede]

Reporting yet another issue. A user of mine reported to me that their birthday was (very clearly) inaccurate. Don't mind the duplicate name history towards the end. That's a glitch with Mojang removing a name from their history and that does show up in the actual API.

Their API URL is: https://api.ashcon.app/mojang/v2/user/lifeispain_326

You can clearly see the birthday is inaccurate considering that the birthday is August 8, 2015... and they changed their name 7 times before that date.

[lucky-swede]

Yeah, something's surely up. "Nimble" is reported to have been made on April 16, 2020, when it was namechanged in 2015.

Another 2009 IGN as well: "jty"

[Electroid]

Alright, thanks for flagging again. My hunch is that sporadic 429s might be "corrupting" some birthdays. In which case, I'll have the purge the cache anyway. Will update when these is progress.

[lucky-swede]

Yeah, the accounts with birthdays after name changes should have their caches purged, if you know what I mean?

Like, Nimble has a name change in 2015 but its birthday is 2020. If the birthday date surpasses the date of the first name change then the cache should be purged for that account.