automatic date parsing ... is this really good?

[kaiko]

At some point it can be good to convert timestamp values to natural Date javascript objects, but currently it will bring problems more than joy.
Easier is to bring example than describe it:

q = workerDB.query('select '
  + ' current_timestamp AS d1,'
  + ' current_timestamp::timestamp(0) AS d2,'
  + ' current_timestamp :: text AS t');
q.on('row', function (r) {
   util.puts(JSON.stringify(r, null, 3));
   util.puts(r.d1.valueOf());
   util.puts(r.d2.valueOf());
   util.puts(r.d1.toString());
   util.puts(r.d2.toString());
 });

Will output:
{
"d1": "2011-01-21T22:59:45.424Z",
"d2": "2011-01-22T00:59:45.000Z",
"t": "2011-01-22 00:59:45.424245+02"
}
1295650785424
1295657985000
Sat Jan 22 2011 00:59:45 GMT+0200 (EET)
Sat Jan 22 2011 02:59:45 GMT+0200 (EET)
2011-01-22 00:59:45.424245+02

As you can see -- time can change depending in what timezone you are.
Don't get me wrong -- I really like this feature but I put system in live without checking enough and ... boom :)
I think using Date object should be configurable and default should be off (and should be very clearly documentated).
Or turned on ONLY with timestamps with timezones but then it is confusing for user.

[brianc]

It seems like you're requesting a feature be removed or disabled because it requires the developer to store dates with specific timezones? Perhaps another example would be in order, but I'm not understanding how this could be an issue unless the developer required timezone information but didn't store it?

Example:

client.query("SELECT (current_timestamp::timestamp(0))::text", Æ(err, result) {
  console.log(result.rows[0])
})

client.query("SELECT (current_timestamp::timestamptz)::text", Æ(err, result) {
  console.log(result.rows[0])
})

this produces

{ now: '2011-01-21 17:27:45' }
{ now: '2011-01-21 17:27:45.401622-06' }

So...either the consumer of node-postgres will have to know "Hey, I get local dates back if I don't specify a timezone. I have to adjust the date objects to the timezone I want to use." or will have to know "Hey, I get difficult to parse date strings back in a non-specific timezone and have to convert them to a date object and then ajust the date objects to the timezone I want to use."

Seems like it would place more burden on the developer while not removing any. But like I said...perhaps I am missing something.

[kaiko]

What will be output if you remove conversion to "text" type in sql?