John Crenshaw wrote:
> Strings have a number of other disadvantages in this case. They take
> more computations to compare, they take time to parse when you read
> them, and they take longer to build when you insert them. Generally,
> storing dates as a number of some sort is ideal.
>
I do agree with that. The problem is that the ideal way to store a date
is different from the ideal way to *display* a date. And that the
conversion between the two has to be done manually.
> Building a query to return the value as a human readable string is
> fairly easy:
> SELECT datetime(2455133.71759947); -- returns '2009-10-29 05:13:20'
>
Yes, it's easy to do that -- *if* you know that the number *is* a date.
This is fine as long as you always view your data with
application-specific tools and never with generic ones.
> I imagine the timezones aren't documented, because they aren't actually
> stored if the Julian format is used internally (they have to be
> converted to get the Julian in UTC.) If you use a string, it can store
> the timezone I guess, but it will cost you in terms of speed.
That's not the point. Timezones can't be part of the return value of
the strftime/datetime/julianday functions, but it's still worth
mentioning that they can be part of the parameter.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
