-
Notifications
You must be signed in to change notification settings - Fork 715
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Test & document date/time handling along with pitfalls #546
Comments
From further discussion in https://groups.google.com/forum/#!topic/phonegap/za7z51_fKRw I think the following SQLite date/time pitfalls can be identified:
Additional SQLite pitfall(s) in general:
I can identify the following TODOs:
In general I would really like to see these items clearly documented by the SQLite project. P.S. I found https://stackoverflow.com/questions/26978342/how-to-store-datetime-in-sqlite through reference at: https://stackoverflow.com/questions/17227110/what-is-the-best-way-to-save-datetime-type-in-sqlite |
Also linking to #415 with another pitfall: no explicit handling of JavaScript Date object |
From discussion in https://groups.google.com/forum/#!topic/phonegap/za7z51_fKRw I suspect date/time handling with JavaScript and SQLite databases can be a bit tricky. (I am not sure about IndexedDB but suspect similar issues with LocalStorage.) I can think of the following ways to store date/time in a SQLite database:
DATETIME
typename has a NUMERIC type affinity)If someone just uses something like Date.now() in a SQL parameter list, its toString() function is called and the plugin would simply store the string value. (I am 99.9% sure that this would be the case for Web SQL as well.) I suspect that it is possible to use the valueOf() member function to get the numeric value.
It can also be tricky to figure out how to use date comparisons when selecting data.
From https://groups.google.com/d/msg/phonegap/za7z51_fKRw/gMCypOCwBQAJ:
(Note that he gave the JavaScript samples with the callback functions cut off.)
I personally think it should be possible and perhaps a little more efficient to use numeric "DATETIME" fields but may well be mistaken here. Unfortunately I cannot promise when I will have a chance to test this.
The text was updated successfully, but these errors were encountered: