On Sat, Feb 28, 2009 at 12:47:07PM -0800, jonwood wrote:
> > Database is for manipulating data. Your UI application is for presenting 
> > it nicely to the user. After all, you don't complain that SQLite, say, 
> > doesn't have functions for formatting numbers in user-friendly manner 
> > (e.g. 123,456.78).
> 
> So why does it have to be pre-formatted by storing it as text that I must
> parse and then reformat? If it just stored a date object in binary
> format--as a database should do--then I could easily format it to present to
> the user.

Why do you have to notice that SQLite3's date type is actually TEXT?
Use the functions provided and don't think of how they work (text
parsing and all that).  Just because a type isn't opaque doesn't mean
that you can't treat it as such...

> > You can store dates as doubles representing Julian dates, or as integers 
> > representing number of seconds since Unix epoch (aka time_t). Is this 
> > the kind of bindary format you are talking about?
> 
> Well, I don't know many CRT routines for working with Julian dates. time_t
> has support but they've kind of moved to a 64-bit version. I guess I could
> store it as a BLOB or store the year, month, day, hour, minute, and second
> in separate fields as well. But that doesn't seem like a very good approach
> to me.

No, no, just use SQLite3's date/time functions to convert to whatever
presentation form you want.  You can use them on the text form of dates
and on the integer form both.

Don't bother writing your own code to do these conversions when they are
already provided for you!

Nico
-- 
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to