I cannot really use toLocalTime() on the client side because the data I have stored in the DB is UTC time.
On client side I expect the value to be as is and I just convert it to local time. So effectively, at this point, I am getting UTC values on client side with toLocalTime().
Bump.
The problem lies with the driver used by knex, it converts database values to javascript objects, in case of the timestamp it is converted to an javascript Date object.
https://node-postgres.com/features/types#date-timestamp-timestamptz
Possible solution is to change the parser for the specific type.
Would that be something that could be done in Wappler such that it works similarly for all users?
Or if its something that I should do on my project specifically, can you please explain where I should put the code as explained in the shared post.
If I would change it in the code for all users it means that it also changes for the users that expect the timestamp to be returned as it is now. We had this before with several users wanted to have some behavior changed and after the change we did get a lot of bug reports because other users did expect the old behavior and reported it as broken. Because of that I’m careful with updating code that would have impact on existing projects.
I think a good place to place the code is in the file lib/setup/database.js. For now I would suggest to just making the changes yourself. Let me know if it is working or not.
That’s understandable. But if the change fixes something, it should be done.
A clear message on the update post should make the users more aware of the change.
Tgere have been many such changes in past, without clear message, which was the reason for majority the bug reports, if not all.
Will try to change the db JS file and see if that fixes it for me in the mean time.
It’s not that simple though…There are plenty of users that upgrade Wappler without even visiting the forum.
Breaking changes should be rare, but when required, maybe something can be added to the upgrade process that alerts the user to any breaking change?
3 Likes
And there are users who skip updates in between too.
There is no way to ensure the user would know there have been breaking changes, in the current way Wappler updates are served.
Having it documented in the community post is the only option as of now.
But this does not mean breaking updates should not be released.
If the team would have a singular place for update history, not this community, with breaking changes marked separately, that would be the best solution.
In any scenario, my point is breaking changes will always be there. Team has released numerous such updates before, without any specific info about them. Its great that Patrick and the team are being more cautious now, but the solution is not to stop releasing breaking updates… Instead a better system for users to know about them BEFORE updating.
1 Like
Yep, good point.
Dealing with breaking changes is tough.
Bubble actually has a pretty good implementation (which is a totally different use case) where the user could choose to update on certain breaking changes. In other words, a bunch of changes were done to the platform as a whole, but there were a few times where the user had to choose an upgrade, at which time the breaking change was communicated.
Different, true. But inspiration can come from anywhere. 
Breaking changes… 
I only upgrade Wappler versions every few months and that is likely to become even less frequent now I am launching my product…
… so I would definitely need a message during the installation process of all breaking changes made in the last year…
I wouldn’t even know where to go to see some message about a release 3 months ago!
1 Like
As concerning as that is, its a valid way to work. And hence my suggestions about various ways to handle such scenario.
In our office, we update 2-3 days after release. We wait out a bit to see any big issues that might have snuck into the update. But we’ve made it a habit to stay on the latest version.
My habit has been to update within 20 minutes of the latest release being announced!
That said, I’ve not gone for v4.0.0 yet because I want to wait for today’s update to be absolutely sure all is well.
I’m not concerned at all…
I need stability, stability, stability, so it just feels very comfortable to me!
I scan all the bug posts, and upgrade on a Tuesday or Wednesday when a release feels particularly solid and if I fancy using some new feature that has come along…
I’m currently wondering what the best way is to handle this date issue with NodeJS. I created some Gantt planning schedule with a javascript library.
But when I add a database record with date “2022-01-01” (Type is Date on Postgress db):
on the front-end dmx.parse outputs “2021-12-31T23:00:00.000Z”:
This doesn’t make a whole lot of sense to me.
How do you guys handle such date/time difference issues?
The DB stored date is ok according to my timezone but during fetching it changes to UTC similar to this format “2021-12-31T23:00:00.000Z”
The solution:
During the wappler custom query in PostgreSql i have used
table.date::text
and its working perfectly.
If you have solved this issue in any other way please comment here.
I am working on my first NodeJS project. I’m converting a PHP project I just started so I figured why not. I already had a login code expiration query working in the PHP version so when I recreated my server connect php files in json the select query for the code expiration date kept returning a javascript Date object and I was banging my head against the wall until I found this post.
Thanks for this post, @sid
-Twitch
1 Like
Node uses the default date to json conversion, you can override the default behavior like:
Date.prototype.toJSON = function() {
const date = new Date(this);
date.setMinutes(date.getMinutes() - date.getTimezoneOffset());
return date.toISOString().slice(0, -1).replace('T', ' ');
}
Where should this be added?