Resolves Issue #294

[buddysal]

creates a variable called splitDate in the data method, splits the date from lastAccess into a date and time variable splitDate[0] is date and splitDate [1] is time, Checks if splitDate[0] is equal to 2024-08-12, if it is true it sets date to true, if it is false it sets date to false, in the comparator in the template if date is true it pulls the date the xp was paid out last rather than the date of last access, if it is false it pulls the date of lastAccess. This should resolve issue #294 around multiple people having the same lastAccess date if they have not logged on since the "places" update was published. There may still be same dates here and there if people have not logged on since the xp payout started.

[dburleson]

Rejecting this pull request as the approach isn't ideal. We should really be looking at resolving the data in the db instead of adding fixed date checks in the code. This is also displaying the last daily login credit, which isn't needed.

[buddysal]

Alright, there really isnt an issue with the db, more so how the data was implemented for the last access date on the places update. Anyone that has no logged on since after the places update was implemented all have the same last access date which is the date the places update was implemented. it will self correct over time, this was just a temporary fix so that so many people did not have the same last access date.

[dburleson]

I've updated the db for those specific records by taking the last daily credit date and setting that as their last activity. It's good enough.