>>Exactly. No 2-digit year format, no AM/PM format, and no way to eliminate
>>leading zeros, etc. Just as I pointed out in my original post.
>
> Well, I would say you (or your users) live in the past.
> The rest of the world uses ISO-8601 ;)
> http://www.cl.cam.ac.uk/~mgk25/iso-time.html
Heh, well, I suppose I could tell the client that I can't match his current
reports, or make the columns narrow enough to all fit on a single page and
see if he still wants to pay me. But, with the economy what it is, I was
toying with the idea of just giving him what he asked for.
>Pun aside, you can always deliver epoch (or something else
>you find more convenient) to your application and let the
>application do the formatting.
>SQL isn't meant for presentation anyway, it's for relational
>storage.
>
>Example:
>Compute the time since the unix epoch in seconds (like
>strftime('%s','now') except this includes the fractional
>part):
>
> SELECT (julianday('now') - 2440587.5)*86400.0;
Right. I think I'm getting the picture of my options. I already have a fair
amount of code working that relies on the a DATETIME column and was hoping
it would support a date format supported by C/C++ (like the way I read
DateTime values with MS SQL and C# in .NET).
I can work something out if these are my options though.
Thanks.
Jonathan
--
View this message in context:
http://www.nabble.com/DateTime-Objects-tp22264879p22268057.html
Sent from the SQLite mailing list archive at Nabble.com.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
