Alrighty, I checked the backups for the past 2 weeks and the results were consistent with my initial guess.
I've attached the relevant CSVs.
Note, all times are in Central Time, so there's a slight day shift here.
Also Note, that all files are named after their backup date (ie 20.csv = April 20th Backup)
For the backup from April 20th, you'll see that the Decay had calculated at and recorded the data it had available at that time.
Between the 20th and the 21st Backup, the X2 raid from a few days prior was added recorded, hence the apparent disconnect between the cumulative total used to decay, and the current cumulative total. The raid was recorded after decay ran.
By contrast, if you compare the 27th and 28th raids, you'll see that the X2 raid from and the decay were both missing in the 27th, but present in the 28th, and the numbers are consistent meaning the raid was recorded before decay ran.
The takeaways from this are as follows:
1) For you: Tax-based and EPGP-type decay, in it's current form is not forgiving of late data entry.
2) For me: Perhaps it's time for me to revisit decay and make it attempt to run the tax-based/EPGP decays retroactively. That way, if you were to enter a raid late, it wouldn't matter - the previously processed decay would adjust itself to the totals at the time. I'll ponder on this
Also, the code that I used to export these CSVs isn't ready for production use, but I've got a whole big CSV system in the works for exporting things for various reasons, mostly analysis.
Finally, thank you for bringing this to my attention.
