ToFix:importing csv is going back all date column 1 day in time
After uploading, accepting the file and validating the columns with the webapp fields, I was careful to verify that all dates in the date column are being anticipated by one day. This does not happen in the import display table, but when the data is registered in the system. I've done several tests and they all return the date by one day. I'm using the Brazil webapp (GMT-3).
-
Jules Randolph commented
This is a classic programming challenge. Below is a likely scenario of what is happening:
- The date is converted by budgetbakers server as a timestamp "at midnight UTC".
- Any client that is leftwards of UTC (minus something) will see the timestamp localized to its timezone. So midnight UTC -3 is interpreted as 21:00 the day before.This is not wrong in absolute terms. It's wrong in terms of UX. The good way would be:
- Provide an option to set the default time and timezone for imported dates;
- Default this timezone as the client timezone;
- Allow for parsing of ISO 8601 dates with time and timezone (that would allow tinkers to decide exactly which timestamp they want to provide).It's probably half a day effort for a standard web developer.
-
Francisco A F Reinaldo commented
I am informing you that, despite being a premium user, I have recently accessed the system again to test whether there have been any improvements in the data importation process. I am currently located in the GMT-3 time zone, so I wanted to verify if this aspect has been addressed. However, no tangible progress has been made since then. It is regrettable.
Given my reliance on this system, I have taken the initiative to develop an alternative solution using JavaScript and Python. I aim to create a system that fulfills my specific requirements by doing so.
I appreciate your attention to this matter and remain hopeful that improvements will be made in the future. Thank you for your understanding.
-
Ricidleiv Tondatto commented
Me too. I'm in UTC-4 (AMT) and I can figure out that the importing service is considering UTC for the dates that was imported. But, it shows the transactions in our local timezone. For example, the attached image shows a transaction that happened in 26.December. After import that, it shows 25.December 20:00, or -4h of 26.Dec 00h00.
My workaround is edit the CSV in Excel, increasing the date by 1 (=A2+1, if "A" is the date column).