New email reporting looks cool, but I queued up an email to send at recipient local time and the “end time” is way off. Anyone have any insight? It would be great to know how many have actually been sent and how many await.
Haha. This is amusing actually. What you’re actually witnessing there is a problem with how Infusionsoft handles errors reporting internally.
In this case, we are almost certainly dealing with what’s known as the UNIX epoch timestamp. The UNIX timestamp measures the number of milliseconds that have passed since January 1st 1970. I can tell that first of all, your timezone locally is GMT-5.
Second, there was some kind of internal error and when the local function failed, the system tried to return an error code or returned a NULL value, but it was read by the system as an actual value instead.
In this case, something internal broke with infusionsoft and it probably returned a NULL when it tried to calculate the end time. The system, rather than crashing spectacularly tried to “cast” the NULL (non-existent value) to something it could use. In this case, an integer… specifically a zero.
So, you’re in GMT-5, and when the system calculated the UNIX epoch timestamp for the end time, it returned 0, then it subtracted 5 hours for your timezone, and you get Dec 31st 1969 at 7PM.
Sadly, there’s likely nothing you can do on your side to fix this. Report it, and try using a new fresh broadcast template and see if it reoccurs.
Thanks for the insights!
Confirming, what @Jason_Crenshaw said. That is exactly what it is. When a date/time in IS isn’t actually set, it defaults to epoch origin time 