## NodeJS
* Improve database resultset, format datetime in local datetime string and check for json
I already see a post about this being a breaking change, as I was fearing as well…
There is no explaination in the release note either.
The problem what was already reported many times is that in NodeJS some databases returned the datetime different than it normally should. It returned 2022-10-21T02:15:00Z instead of 2022-10-21 13:15:00.
The other improvement is that with some databases the resultset the json field was not parsed and returned the stringified json instead. This should now return the json object correctly.
This is going to break every single one of our Postgres projects, and also probably MySQL ones.
This was reported more than an year ago, when you didn’t want to change it because it would break other people’s implementation. Now after a year that we have built complex system around the issue, you have done what was feared - released a massively breaking change - without even an explanation in the release notes.
Please add an option to enable/disable this change per project basis, so we can make use of this fix in newer projects, and gradually update the existing ones.
2 Likes
I second this 
The newer projects will be okay as we know the database values that will be returned. But in the older projects, I don’t think it will be an easy and quick process to find every instance of datetime usage, which could be tens or hundreds of places depending upon the project complexity, and refactor the code to implement the latest changes. The old code may be left behind in the existing projects, which may not get picked up when fixing the changes.
Well it is kind of weird to add an option for yes “please use old buggy behavior dependent per database”, while we actually finally solved the database difference in handling dates and make them all work exactly the same now.
We do consider an option to thread dates always as local (standard now) or as UTC (where you will need to convert them your self to local - this was a bit the node behavior that needed fix every time but also was very much database dependent)
I think I was always using “.toUTC” because “.toLocal” wasn’t doing anything different. So the breaking change will be only in places where “.toLocal” is used right? Just to make sure that I can update my Wappler version
Or is this related to all places where datetime fields are returned? In that case it’s quite a problem indeed
It’s not working as per the example given by Patrick in his reply (I added this reply in my post also). The value is not being returned in local time; it’s returning UTC time, the same value that’s saved in the db. So, this change is not working as intended in the latest version.
I see this as more “please leave the behaviour alone so it works with the apps as they have been built to accommodate the ‘buggy behaviour’ and allow us to switch to the new behaviour in a controlled manner”
I think that is probably the best solution, having the option to change it. Will probably do it per database connection since all behave different. Options could be Driver default, Local and UTC with the driver default being the old behavior per database.
3 Likes
You’ve set your docker to UTC timezone, so that will be the local timezone on the server while the client timezone is different and when datetime on the client is received as local then it thinks that it is in the client timezone while the string was in the server timezone.
We will be working on an update to support the old and the new way with a separate option, we are currently looking on where we should put this option, what the default should be and which databases are exactly affected.
1 Like
I third it.
Thanks for the prompt decision on adding a setting for this.
Hope it can make it to the next release.
Just wanted to chime in and say this also broke my project, with all time based data being displayed to the local user in UTC time as per the DB, instead of displaying in the browsers local timezone as it was pre update.
Changing the timezone for the docker container did fix the issue, but not sure if that is the best practise as then different users in different time zones would get incorrect time displayed.
I rolled back to 5.2.0 as i don’t have the time right now to look into fixing my code to work with the update etc so will watch this space.
1 Like
This has been improved in Wappler 5.2.2
We’ve added a few options to handle the date & time for NodeJS, which also include the legacy driver default option. Please check:
This topic was automatically closed after 47 hours. New replies are no longer allowed.