On 10/23/19, Darren Duncan <dar...@darrenduncan.net> wrote: > On 2019-10-23 10:36 a.m., Richard Hipp wrote: >> On 10/23/19, Peng Yu <pengyu...@gmail.com> wrote: >>> >>> Only integer is allowed for last modification time. Why not allow >>> subsecond file modification time in sqlar format, given subsecond time >>> is allowed in many OSes? Thanks. >>> >>> mtime INT, -- last modification time >> >> The datatypes for table columns in SQLite are suggestions, not >> requirements. The implementation could be enhanced to store the mtime >> as a floating-point value, and everything would continue to work the >> same. > > Why float? Shouldn't a standard 64-bit integer be able to represent all the > subsecond time precision people would want? -- Darren Duncan
You *could* do it that way, but doing so what change the meaning of the mtime field. Instead of representing seconds since 1970, it would now represent microseconds since 1970, or something similar. That means any legacy code that used mtime and understood it by its old meaning would break. It also means that legacy databases that recorded mtime in units of seconds would give incorrect answers with newer versions of the archiver program that interpret mtime in microseconds. So you run into all kinds of compatibility and upgrade complications. On the other hand, if you just let mtime be a floating point value, all the legacy applications and legacy database files continue to work. Everything is fully backwards-compatible. -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
