In applications dates/times are input, dates/times are output. Commonly the storage format of dates/times is of no concern. More effort is often spent on time zone display and input, which is an application issue rather than a data store issue. (e.g. fossil) All one *needs* is database functions to input what you output (and vice versa), For me, the major benefit of a database "date/time" types is clarity for humans when reading the schema. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
- Re: [sqlite] Backward compatibility vs. n... Simon Slavin
- Re: [sqlite] Backward compatibility vs. n... Thomas Kurz
- Re: [sqlite] Backward compatibility vs. n... Simon Slavin
- Re: [sqlite] Backward compatibility vs. n... Thomas Kurz
- Re: [sqlite] Backward compatibility vs. n... Keith Medcalf
- Re: [sqlite] Backward compatibility vs. n... Ling, Andy
- Re: [sqlite] Backward compatibility vs. n... Dominique Devienne
- Re: [sqlite] Backward compatibility vs. n... Ling, Andy
- Re: [sqlite] Backward compatibility vs. n... Peter da Silva
- Re: [sqlite] Backward compatibility vs. new features (... Keith Medcalf
- Re: [sqlite] Backward compatibility vs. new featu... D Burgess
- Re: [sqlite] Backward compatibility vs. new featu... Tim Streater
- Re: [sqlite] Backward compatibility vs. new featu... Thomas Kurz
- Re: [sqlite] Backward compatibility vs. new f... Tim Streater
- Re: [sqlite] Backward compatibility vs. n... Simon Slavin
- Re: [sqlite] Backward compatibility vs. n... J Decker
- Re: [sqlite] Backward compatibility vs. n... Tim Streater
- Re: [sqlite] Backward compatibility vs. n... J Decker
- Re: [sqlite] Backward compatibility vs. n... Stephen Chrzanowski
- Re: [sqlite] Backward compatibility vs. n... Warren Young
- Re: [sqlite] Backward compatibility vs. n... Stephen Chrzanowski