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