Permalink
Browse files

Merge pull request #514 from benighted/parse-date-as-local

Parse date type as local time
  • Loading branch information...
brianc committed Feb 26, 2014
2 parents ff8fb61 + b81a60a commit 2716f95257fc768423cd703f830be5d2a387ba73
Showing with 5 additions and 3 deletions.
  1. +2 −1 lib/types/textParsers.js
  2. +3 −2 test/integration/client/type-coercion-tests.js
View
@@ -14,7 +14,8 @@ var parseDate = function(isoDate) {
return null;
} else {
//it is a date in YYYY-MM-DD format
- return new Date(isoDate);
+ //add time portion to force js to parse as local time
+ return new Date(isoDate + ' 00:00:00');
}
}
var isBC = /BC$/.test(isoDate);
@@ -202,13 +202,14 @@ helper.pg.connect(helper.config, assert.calls(function(err, client, done) {
if(!helper.config.binary) {
test("postgres date type", function() {
var client = helper.client();
+ var testDate = new Date (2010, 9, 31);
client.on('error', function(err) {
console.log(err);
client.end();
});
- client.query("SELECT '2010-10-31'::date", assert.calls(function(err, result){
+ client.query("SELECT $1::date", [testDate], assert.calls(function(err, result){
assert.isNull(err);
- assert.UTCDate(result.rows[0].date, 2010, 9, 31, 0, 0, 0, 0);
+ assert.strictEqual(result.rows[0].date.toString(), testDate.toString());
}));
client.on('drain', client.end.bind(client));
});

3 comments on commit 2716f95

@enthal

This comment has been minimized.

Show comment Hide comment
@enthal

enthal Mar 14, 2014

Why local time? Our dates are stored UTC.

Why local time? Our dates are stored UTC.

@brianc

This comment has been minimized.

Show comment Hide comment
@brianc

brianc Mar 14, 2014

Owner

I believe PostgreSQL itself recommends you return dates in the client timezone unless the timezone is specified (as it is in TIMESTAMPTZ data type).

Good news is I haven't released this code yet, and since it's a breaking change it wont happen until I bump the major version number to 3. For the v3.0 release I'm going to try to spin the type system out into its own module and better document how implement your own type parsers so if you'd rather have your dates considered UTC all the time you can easily override that behavior.

Owner

brianc replied Mar 14, 2014

I believe PostgreSQL itself recommends you return dates in the client timezone unless the timezone is specified (as it is in TIMESTAMPTZ data type).

Good news is I haven't released this code yet, and since it's a breaking change it wont happen until I bump the major version number to 3. For the v3.0 release I'm going to try to spin the type system out into its own module and better document how implement your own type parsers so if you'd rather have your dates considered UTC all the time you can easily override that behavior.

@benighted

This comment has been minimized.

Show comment Hide comment
@benighted

benighted Mar 14, 2014

Contributor

The problem is basically that javascript parses a timestamp as local time unless it is in valid ISO-8601 format, ie "YYYY-MM-DDTHH:MM:SS", but postgres uses a format like "YYYY-MM-DD HH:MM:SS" (note the space instead of letter "T") which is not valid ISO-8601. To standardize the behavior, it was decided to also parse the Date type as local time as well, even though it is technically valid ISO-8601 without the time portion. This was discussed in issue #510 if you are still curious.

Contributor

benighted replied Mar 14, 2014

The problem is basically that javascript parses a timestamp as local time unless it is in valid ISO-8601 format, ie "YYYY-MM-DDTHH:MM:SS", but postgres uses a format like "YYYY-MM-DD HH:MM:SS" (note the space instead of letter "T") which is not valid ISO-8601. To standardize the behavior, it was decided to also parse the Date type as local time as well, even though it is technically valid ISO-8601 without the time portion. This was discussed in issue #510 if you are still curious.

Please sign in to comment.