DateTime returning incorrect time in 2.0.0 & 2.1.0 for get request

[vespertilian]

Sample app for testing this here: It's just a base install, s simple model and branches for the different versions of the loopback-connector-postgresql

https://github.com/vespertilian/loopback_datetime

2.1.0 & 2.0.0

Data:

{
  "testDate1": "2015-06-10T01:11:06.774Z"
}

Response: correct

{
  "testDate1": "2015-06-10T01:11:06.774Z",
  "id": 5
}

Get /DatePostgres/:id (5)
Response: ***** incorrect

{
  "testDate1": "2015-06-09T15:11:06.774Z",
  "testDate2": null,
  "testDate3": null,
  "id": 6
}

1.7.1

Data:

{
  "testDate1": "2015-06-10T01:11:06.774Z"
}

Response: correct

{
  "testDate1": "2015-06-10T01:11:06.774Z",
  "id": 5
}

Get /DatePostgres/:id (5)
Response: correct

{
  "testDate1": "2015-06-10T01:11:06.774Z",
  "testDate2": null,
  "testDate3": null,
  "id": 5
}

DB table view with PG-Commander

Both the dates are saved in my local timezone (Sydney). Would be good if they respected the timezone the were submitted in. I am keen to store everything in UTC and convert it on the front end.

testdate1: 2015-06-10 11:11:06.774+10 id: 5
testdate1: 2015-06-10 01:11:06.774+10 id: 6

Thanks
Cameron

[mfrye]

👍 I believe I'm having the same problem.

[mfrye]

Actually it looks like it was fixed two days ago:

#88
https://github.com/strongloop/loopback-connector-postgresql/blob/master/lib/postgresql.js#L454

Note to the team, I just started using loopback over the past couple weeks and I've been evaluating whether or not to continue using it. I was stuck on this bug for over day.

I appreciate all of the work that you've done on this, but this seems like a very simple bug that should have never made it to release.

[vespertilian]

Yep looks fixed. Thanks for bringing that to my attention @mfrye

As for loopback, I have been using it for about 6 months now and am enjoying the experience. The auto swagger generation has been a great when working with our iOS developer. Auto-generation of angular factories saves loads boilerplate angularjs code. The other reason for choosing loopback is the Strongloop guys seem to be working hard on making deployment a breeze, it’s a real end to end solution for building an API.

I would encourage you to stick with it.

With the bug, I think one of my tests picked this up a month ago, but I was confused if it was strongloop or me as I had just done a huge refactor and did not look into properly until last week, my code is not yet in production so it was not a priority.

Hopefully my tests (and your tests) will pick up similar bugs. We can report them quicker, giving the Strongloop guys a chance to look into it. That’s the advantage of open source. It's a bit weird no else noticed this bug for a month.

[ssh24]

Closing this issue as it has been fixed.

@vespertilian @mfrye Sorry for the inconvenience. And thank you for using LoopBack!