That still wouldn't explain why the "since" value starts at 0000-00-00. (if you capture all the requests, you can see this in the SOAP call)

I was looking through the source code and I can't find anything which actually checks the "since" date is valid.

6 minutes to go from 0000-00-01 up to 2019-03-12 seems about right.

We make the GetDomainStatistics API Call to Smartermail with the startdate and EndDate.

Would you be able to make the API call for us against your Smartermail server to see what happens if the start date is blank?

6 minutes is for the bandwidth to be collected on all hosting spaces (As a test server it has alot of different spaces and providers). If this acts as you explain i would expect it to have a large different between the first and second time it is ran as the second time the BandwidthUpdated has a value.

Trevor.

The start date (in the $POST SOAP value call to Smartermail svcDomainAdmin.asmx) isn't blank, it's 0000-00-01 and then increments over and over.

Sadly I have deleted all the traces now or I could send them to you to see.

The question is - if the bandwidth collection on an email only package hasn't been run before, which date do you send as the StartDate?

Ok i see what you mean that there is a loop that looks at the date starting with 1/1/0001 and then increases this value by 1 day before doing the API call again.

It looks like alot of the providers do the same but they are generally checking files and not making an API call.

I think the easy solution for all is that when the package is added we set a BandwidthUpdated value. The question is should we make this date the day the package is created or something more generic like a year before to cover any imported packages?

Could it not do both? If it's a new account set the date as today (or yesterday?) but on an import, like you said, maybe put it a year back (I think that would cover most users!)