On 2 Apr 2012, at 6:18pm, Alexey Pechnikov <pechni...@mobigroup.ru> wrote:
> Please see http://www.sqlite.org/lang_datefunc.html and you will be > frustrated because SQLite can format date/time to different string formats > but can't read the produced date/time strings. I am not frustrated. That function does not require any understanding of locales, timezones, or Summer Time. It doesn't 'understand' dates at all, it's just a version of sprintf() useful for dates. Easy to write, easy to test. Turning dates into arbitrary strings is easy. Adjusting for time zones is difficult. Analyzing a string to turn it into a date is difficult (some strings are ambiguous), and may require support for Unicode which is very difficult indeed. This is a complicated thing and putting such functions on tiny devices like a GPS Unit would be a big waste. If you want external functions, SQLite supplies very nice facilities which let you plug them in. No need to patch the source code. So you can write your functions to convert your dates however you want, with whatever understanding of locales you want. I think a future version of SQLite might handle dates. But a higher priority than that would be handling Unicode correctly. And having Unicode support would be useful in writing the code which handles dates. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
