Timestamp Column Converted to UTC In Wappler

Server Side Components General
#18

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
#19

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.

#20

Different, true. But inspiration can come from anywhere. :wink:

#21

Breaking changes… :exploding_head:

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
#22

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.

#23

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.

#24

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…

#25

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):
date in db editor

on the front-end dmx.parse outputs “2021-12-31T23:00:00.000Z”:
datefrontend

This doesn’t make a whole lot of sense to me.

How do you guys handle such date/time difference issues?

#26

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.

#27

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
#28

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', ' ');
}
Postgres ::date not working on Custom Query
#29

Where should this be added?

#30

I think easiest is to place it directly in the index.js before the server.start().

#31

Could probably make an option for it in Server Connect where you choose how datetime should be returned from server actions.

#32

That would be great. In our existing projects, maybe we will be able to simplify bindings with the help of this.

#33

With the next update you will have an option to set the output format of datetime fields from the database, you can set it to a local or utc string.

1 Like
#34
#35

This has been improved in Wappler 5.2.2
We’ve added a few options to handle the date & time for NodeJS. Please check:

#36
#37

This topic was automatically closed after 47 hours. New replies are no longer allowed.