We are capturing time parting values into the eVar. We slightly amended the plugin, so now it collects data in the format "2017-01-30 12:22:12|Monday".
When I looked at the data for 30 January 2017 I noticed that some values were related to the previous dates, e.g. 26 January, e.g. "2017-01-26 13:33:10". eVar32 expires on visit. Hence I don't understand how can this be happening. This value shouldn't exist during the visit on 30 January. Additonal detail: usually this incorrect time parting value is associated with Order.
We copy eVar into prop but props have 30 January 2017 values.
I am trying to understand the scenario how the this value could be populated. I have a certain percentage of orders with a wrong time parting values and would like to understand the scenario.
My first suggestion would be to confirm that your eVar is set up properly. Can you confirm for me what the Allocation setting of the eVar is? I saw above that you had planned for it to expire on visit. Normally I'd say there will be a very small amount of mismatch between the value and the date due to visits that start before midnight and end after midnight, but that obviously is different than the 4-day difference you are seeing! However, if your eVar allocation is set to Original (instead of Most Recent) then it would make sense how this could happen.
I believe now that it has to do with some user browsers time settings which are incorrect. There is just a small percentage of these visits. However, what remains a mystery to me is that how prop can have a different value if it is copied form eVar.
Just out of curiosity even if eVar32 has Original allocation & given that it expires on visit (per above conversation), is it feasible that the report run for 30 January day had 26 January as time parting value for eVar32 variable? It would be worth for me to understand this.