> > I must agree with other posters that the lack of an exposed timestamp > > type does feel like something of a gap. > > Given the rather large number of reasonable ways to represent > timestamps, I have to disagree. I'd rather have the freedom to use > whichever representation is best for my needs. > > E.g., if a table contains rows representing Unix files, then I'll > probably want to store seconds since the Unix epoch because that will > mean fewer conversions, depending on how I use that table anyways.
An internal timestamp type wouldn't force you to use it. Remember you still have dynamic typing. You could choose to store an integer instead and that would be fine. The point is that it would be good to have an internal type specifically for storing time, just like there are types for real numbers, integers, blobs, and text. Time could be stored as it is now (a real number) with perhaps a timezone, but would have a distinct type identifying it. I expect the reason this isn't done is that at the SQL level there is no wonderful way to recognize a constant as a "time". The data type would mostly only be relevant when binding, where the strong typing of the API clarifies things. John _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
