Conversation
Dates are stored in SQLite as Unix timestamps. Dates are represented in JavaScript as Unix timestamps. Thus, there need not be any sort of conversions. Client-side timezones are irrelevant; they should only affect the client-side display of dates. The existing code is incorrect because it's storing timezone-offset dates _as UTC dates_ (with the "Z" suffix). This change simplifies the type conversion; a Date is stored as an ISO-8601 date string, which is understood by both JavaScript's `Date` constructor and SQLite.
apoco
force-pushed
the
sqlite-utc-dates
branch
from
c5ee2ea to
8d44a83
Compare
|
Looks good, I'll just have to run this against ORM |
|
Great. I have some changes locally that work in conjunction with this, but I hesitated creating a PR since it won't pass without this package's updates. Would it be helpful for me to put a PR together, or is this pretty straightforward? Another option that occurred to me is maybe having a different data type for this, like |
|
I've continued discussion in dresende/node-orm2#568 |
| assert.equal( | ||
| dialect.escapeVal(new Date(d.getTime()), '-0400'), | ||
| "'2013-09-04T15:15:11.133Z'" | ||
| "'2013-09-04T19:15:11.133Z'" |
There was a problem hiding this comment.
I suspect this test will fail on slower machines.
It should probably use http://sinonjs.org/releases/v4.4.2/fake-timers/ instead.
2 participants
Dates are stored in SQLite as Unix timestamps. Dates are represented in JavaScript as Unix timestamps. Thus, there need not be any sort of conversions. Client-side timezones are irrelevant; they should only affect the client-side display of dates. The existing code is incorrect because it's storing timezone-offset dates as UTC dates (with the "Z" suffix).
This change simplifies the type conversion; a Date is stored as an ISO-8601 date string, which is understood by both JavaScript's
Dateconstructor and SQLite.