Cannot store/retrieve UTC dates in sqlite

Version: 2.1.19

When retrieving a Date previously stored in an SQLite database, the date comes back with an offset tacked on, presumably based on the local timezone:

var now = new Date();
things.create({ id: 1, someDate: new Date() });

things.get(1, function(err, thing) {
  var diff = now.getTime() - thing.someDate.getTime();
  // expected: 0, actual: 25200000 (7 hours)
});

I saw in the docs that some of the database engines accept a timestamp option, but SQlite is not one of those engines. Indeed, adding a ?timezone=Z did not remedy the situation.

Is there a way to treat dates as UTC using SQLite? Better yet, is there any way to treat all dates as UTC (as all dates should always be) for all database engines? I realize that as a workaround I can use string dates or make the column numeric and store just the timestamp, but it would be super convenient to just use Date objects and not worry about it. I would expect the same Date I stored would be the same Date coming back, not a new Date with an offset applied.

[apoco]

I think I tracked down the problem to the valueToProperty function. Here’s my findings:

• The timezone option in the query string is being passed to the driver; I’m using ?timezone=Z.
• Dates are being stored as strings.
• The date strings have the correct, expected value, and are expressed in UTC. Example: 2014-10-28T12:11:36.938Z.

valueToProperty then messes up this value. It does the following sequence:

1. value = new Date(value) = good, gives the expected Date.
2. value.setTime(value.getTime() - (value.getTimezoneOffset() * 60000)); = wrong; injects an offset into a date that is already correct.
3. value.setTime(value.getTime() - (tz * 60000)); = does nothing in my case, since my tz is 0.

It looks like the intent for this logic is to be the inverse of the sql-query dateToString method, but it’s not quite right.

It seems to me that this could all be greatly simplified:

1. When storing a Date, store the result of value.toISOString().
2. When retrieving a Date, do a new Date(value).

This way, there is no need to worry about local timezones at all. What are your thoughts?

[erikreppen]

@dxg UTC with timezone or without should make no difference to the JS Date object as long as there were no shenanigans like the ones described by apoco and there’s nothing in the server environment causing confusion about local time when the date object set in the first place.I agree though. Why have it there by default. As raw UTC will help more devs learn how to handle timestamps properly by handling them less outside of the client.