Hi, I'm really sorry I am no longer able to reproduce this, but I can confirm this odd behaviour occurred on a bot of mine. The bot had been running for a few weeks, and one command which created a sorted list of guild.members by Member.joined_at failed. This screenshot of a [p]debug command (a poor man's version of [p]eval) shows an incomplete list of all users in a guild who had joined_at as None, which totalled to 572 users (out of ~3200 in the guild):

Restarting the bot fixed the issue, but I figure the fact that it occurred in the first place means that it ought to be tracked. I'm sorry I did not try to gather more info before restarting the bot.
I am not exactly sure on the steps that cause this to happen but I feel like joined_at being None should probably be documented as intended now that there is the ability to turn off chunking in Client.__init__. Basically, when a member is received through PRESENCE_UPDATE (offline -> online) then they do not have joined_at exposed at an API level. Only through requesting guild members through GUILD_MEMBER_CHUNKS do we receive this information. Since sometimes chunking can fail during on_ready and the like, this seems like you receiving members through regular PRESENCE_UPDATE flow. Some events have a member key which for some reason does have joined_at (the original complaint was that joined_at was too bandwidth consuming) so maybe I should update the cache joined_at if set to None and they send a message.
If you want to fix this, you will have to call Client.request_offline_members for the guild.
Just a warning for anyone currently using this method, it is no longer safe to do so. With the new server discovery thing (see https://github.com/DJScias/Discord-Datamining/commit/977bd10e4180e09dcb5ca49da5b82b2db96ca8b2#commitcomment-32146369), discord added a lurker mode.
You can have member objects without a joined_at attribute with this being the intended behavior now.
This means any bot on a server with server discovery enabled can end up calling Client.request_offline_members continuously if they have any code which is currently relying on this as a workaround for the prior issue.
The only safe method going forward is to handle joined_at with NoneType safe methods.
This does pose a problem for members who aren't lurking and have ended up with a lack of a joined at date though, and (at least in my opinion) makes updating the member cache from other events worth considering.
Most helpful comment
I am not exactly sure on the steps that cause this to happen but I feel like
joined_atbeingNoneshould probably be documented as intended now that there is the ability to turn off chunking inClient.__init__. Basically, when a member is received throughPRESENCE_UPDATE(offline -> online) then they do not havejoined_atexposed at an API level. Only through requesting guild members throughGUILD_MEMBER_CHUNKSdo we receive this information. Since sometimes chunking can fail duringon_readyand the like, this seems like you receiving members through regularPRESENCE_UPDATEflow. Some events have amemberkey which for some reason does havejoined_at(the original complaint was thatjoined_atwas too bandwidth consuming) so maybe I should update the cachejoined_atif set toNoneand they send a message.If you want to fix this, you will have to call
Client.request_offline_membersfor the guild.