This is an issue we are investigating Importing dates in different formats. Could you provide an example of the formats in your file that you use and if the end result is the wrong date value entered in Salesforce or if you receive an error when using the Import module?
One thing I can suggest is that if you're using D/MM/YYYY instead use DD/MM/YYYY to see if you get better results.
Thank you for your post we really appreciate your engagement!
Did you mean I should try uploading in American date format rather than UK format?
If so, I tried that. The format I used was 09/02/2023 (which I then switched around to 02/09/2023) trying to do an update (import) on this field. The import completed successfully with no error messages.
The date I actually got in the record in Salesforce however was 01/09/2023. I am wondering if this is anything to do with time zones as I have come across this before. Perhaps 00:00:00 on 2nd September UK (summer) time is 23:00:00 GMT / UTC on 1st September. All I can say is that I did not have this issue in v2.91. This could be an anomaly we have in our Salesforce instance and not related to Demand Tools, but I could do with a solution or at least a work around to the date issue ASAP please.
If the issue was you were receiving an error I did mean uploading UK format, just to ensure that the month and date values both have 2 digits. DD/MM/YYYY and not D/MM/YYYY or D/M/YYYY. But since it is about the date value being off by 1 you can ignore this.
What you described above about the timezones is correct as to why the date is 1 day behind from the value you had in your file. It happens when your machines time zone is east of GMT.
I just did a test with these settings on my machine (UTC +01:00) , Country or Region = United Kingdom and I see this same behavior that you are reporting.
The only workaround I have found so far in troubleshooting the issue is switching the timezone on my machine to (UTC +00:00)
Let me get this information into a Support ticket to further investigate this behavior. When we find a resolution I will reply on this thread for other members to see.
Hi @AnthonyValidity I haven't no, I was under the impression from @DanW_Validity 's comments on 8th Feb that he would be raising a ticket to cover this...
I didn't see that bit - thank you. I'm going to verify a ticket is created. Either way, we'll have one ready so that when the solution is released you'll be notified 🙂
Until then, the workarounds are to change your time zone in SF to GMT or something West of GMT or to offset your dates by a day to correct the issue.
Anthony Lardiere Jr Senior Customer Success Manager
Thanks for the tip @AndreSchilha ! I have tried this and can confirm that this does work. 👍
I'd have to call this a workaround rather than a solution, as this is unfortunately not one of the standard date formats in Excel and it will require me manually changing the formating of the data I receive before I can upload it through DTV. It would be great if Validity are able to offer a more permanant solution which would avoid this extra step. 🤞
