>Because that's locale-dependent. Some countries, like the US, use >month/day/year; most other countries use day/month/year.
Maybe. Canada supposedly uses the day/month/year format, or so I suddenly became aware of in 1998 when I was in my mid 30's. Prior to that day it was m/d/y. Then again, ever since I was 12 it was always y-m-d. And the hours always went from 00 to 23. >To interpret such a date string, SQLite has to know what country's >customs to use. And that is a pretty significant problem, since: > >- Different operating systems communicate locale info in completely > different ways >- The locale settings may not be applied at the layer of the OS where > SQLite is running (example: Android only very recently started setting > the C-level locale to match the GUI locale.) >- The current locale may not match the locale from which the date string > originates Not to mention that whoever you have appointed as the "authority" for "locale" probably has no bloody clue. Plus of course if I get on an airplane and fly to Japan the locale is completely different from if I hop on a plane and fly to Amsterdam, and still different again if I fly to Miami. No date entered in any one of those locale's will be parseable in any other. In other words a date format of YYYY-MM-DD HH:MM:SS.SSSSSSSSS TZ can always be unambiguosly parsed. The others only perhaps maybe sometimes occassionally. -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
