Why not allow subsecond file modification time in sqlar format?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Why not allow subsecond file modification time in sqlar format?

Peng Yu
Hi,

https://www.sqlite.org/sqlar.html

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

--
Regards,
Peng
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Why not allow subsecond file modification time in sqlar format?

Richard Hipp-3
On 10/23/19, Peng Yu <[hidden email]> wrote:
> Hi,
>
> https://www.sqlite.org/sqlar.html
>
> 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.
--
D. Richard Hipp
[hidden email]
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Why not allow subsecond file modification time in sqlar format?

Peng Yu
But what about `sqlite3 -Atv`? I think it only supports INT time?

On 10/23/19, Richard Hipp <[hidden email]> wrote:

> On 10/23/19, Peng Yu <[hidden email]> wrote:
>> Hi,
>>
>> https://www.sqlite.org/sqlar.html
>>
>> 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.
> --
> D. Richard Hipp
> [hidden email]
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>


--
Regards,
Peng
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Why not allow subsecond file modification time in sqlar format?

Darren Duncan
In reply to this post by Richard Hipp-3
On 2019-10-23 10:36 a.m., Richard Hipp wrote:

> On 10/23/19, Peng Yu <[hidden email]> wrote:
>> Hi,
>>
>> https://www.sqlite.org/sqlar.html
>>
>> 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
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Why not allow subsecond file modification time in sqlar format?

Richard Hipp-3
On 10/23/19, Darren Duncan <[hidden email]> wrote:

> On 2019-10-23 10:36 a.m., Richard Hipp wrote:
>> On 10/23/19, Peng Yu <[hidden email]> 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
[hidden email]
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users