Another reason: because PostgreSQL supports it as well (including timezone) ;-)
- Original Message -
From: Peter da Silva
To: SQLite mailing list
Sent: Tuesday, August 13, 2019, 23:18:29
Subject: [sqlite] Backward compatibility vs. new features (was: Re: dates,
times and R
Yep, I agree, to which is where I pointed out that you'd need the
additional information for that store location. But that's all you'd need,
and only in that one location. Your UI (Or whatever specialized report
generation) would have to do the math from the UTC time, and convert it
accordingly
On Aug 14, 2019, at 9:55 AM, Stephen Chrzanowski wrote:
>
> On Tue, Aug 13, 2019 at 7:30 PM J Decker wrote:
>
>>> Why are you storing the timezone? You display the TZ of the user who is,
>>> later, viewing the data. And that user could be anywhere.
>>
>> Because the actual time on the clock
On Tue, Aug 13, 2019 at 7:30 PM J Decker wrote:
>
> > Why are you storing the timezone? You display the TZ of the user who is,
> > later, viewing the data. And that user could be anywhere.
>
> Because the actual time on the clock on the wall matters.
> I want to know cashiers that are making
On Mon, Aug 12, 2019 at 6:54 AM Tim Streater wrote:
> On 12 Aug 2019, at 14:30, J Decker wrote:
>
> > On Mon, Aug 12, 2019 at 5:42 AM Simon Slavin
> wrote:
> >
> >> On 12 Aug 2019, at 1:27pm, Tim Streater wrote:
> >>
> >> > I don't expect to do that with SQL. My "seconds since the epoch" is
>
If the datr/time is stored internally as utc iso8601 text then it will
remain compatible with old versions and can implement whatever new behavior
is needed on new versions. The bigger question is 'what new behavior'? The
only nee behavior seems to be 'let this third party package see it as a
> > > This is what I would call "forward compatibility": You expect an old
> > application
> > > to be able to read file formats of a future version. Do you have an
> > example
> > > where there is really required?
> >
> > I have an Android app that lets you share the database between users. The
>
On Tue, Aug 13, 2019 at 10:58 AM Ling, Andy
wrote:
> > This is what I would call "forward compatibility": You expect an old
> application
> > to be able to read file formats of a future version. Do you have an
> example
> > where there is really required?
>
> I have an Android app that lets you
> This is what I would call "forward compatibility": You expect an old
> application
> to be able to read file formats of a future version. Do you have an example
> where there is really required?
I have an Android app that lets you share the database between users. The
app will run on a variety
On Monday, 12 August, 2019 13:52, Simon Slavin wrote:
>On 12 Aug 2019, at 8:20pm, Thomas Kurz wrote:
>> c) To enable the new DATE interpreation, we do:
>> CREATE TABLE TEST VERSION=3.34 --> will be stored the same way
>And now you have a file which can't be edited with old versions of
>the
> And now you have a file which can't be edited with old versions of the CLI.
> However you cut it, you have compatibility problems.
One shouldn't do it at all. It's like trying to a edit a DOCX with Word95. It's
not *backward* compatibility. It's not the case you mentioned before. And
On 12 Aug 2019, at 8:20pm, Thomas Kurz wrote:
> c) To enable the new DATE interpreation, we do:
> CREATE TABLE TEST VERSION=3.34 --> will be stored the same way
And now you have a file which can't be edited with old versions of the CLI.
However you cut it, you have compatibility problems.
> A programmer uses a copy of the SQLite CLI to correct errors in a database
> made and maintained by a production program. This involves making a new
> table, copying some data from the old data to the new table, deleting the old
> table, then renaming the new table. When the programmer is
On 12 Aug 2019, at 6:01pm, Thomas Kurz wrote:
>> This would break backward compatibility. It is necessary to be sure that
>> database files made with current versions of SQLite can be opened with old
>> versions back to 2013.
>
> This is what I would call "forward compatibility": You expect
> This would break backward compatibility. It is necessary to be sure that
> database files made with current versions of SQLite can be opened with old
> versions back to 2013.
This is what I would call "forward compatibility": You expect an old
application to be able to read file formats of
On 12 Aug 2019, at 14:30, J Decker wrote:
> On Mon, Aug 12, 2019 at 5:42 AM Simon Slavin wrote:
>
>> On 12 Aug 2019, at 1:27pm, Tim Streater wrote:
>>
>> > I don't expect to do that with SQL. My "seconds since the epoch" is
>> based on converting any particular time to GMT and storing that.
On Mon, Aug 12, 2019 at 5:42 AM Simon Slavin wrote:
> On 12 Aug 2019, at 1:27pm, Tim Streater wrote:
>
> > I don't expect to do that with SQL. My "seconds since the epoch" is
> based on converting any particular time to GMT and storing that. That
> number is then converted to a date/time with
On 12 Aug 2019, at 1:27pm, Tim Streater wrote:
> I don't expect to do that with SQL. My "seconds since the epoch" is based on
> converting any particular time to GMT and storing that. That number is then
> converted to a date/time with TZ info for display.
I'm with Tim. Storing the time zone
On 12 Aug 2019, at 12:41, Thomas Kurz wrote:
> The problem is not only about storing an arbitrary integer or float number. A
> date is much more, it has timezone information with it, and I would like to
> see a DATE column handle this in a proper and well-defined way, just as a
> calendar
> Since date/time is stored as an offset in some units from an epoch of some
> type, the "datatype" declaration is nothing more than an annotation of an
> already existing double or integer type -- and you can already annotate your
> select column names and table attribute type declarations
On 12 Aug 2019, at 00:43, Keith Medcalf wrote:
> On Sunday, 11 August, 2019 16:02, Richard Damon
> wrote:
>
>>On 8/11/19 4:21 PM, Thomas Kurz wrote:
>
I do understand the value of having date/time types in SQLite, but
it is not easy to do while retaining backward compatibility.
>
>
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
On Sunday, 11 August, 2019 16:02, Richard Damon
wrote:
>On 8/11/19 4:21 PM, Thomas Kurz wrote:
>>> I do understand the value of having date/time types in SQLite, but
>>> it is not easy to do while retaining backward compatibility.
I do not see any value in having a date/time type is
On 11 Aug 2019, at 11:51pm, Thomas Kurz wrote:
> I don't see a huge problem here. Does the database file have a version number
> indicating which version the file has been created with? If so, newer SQLite
> libraries could easily emulate the old-style behavior by just checking this
> version
> The issue for something like a data-time field is how would you indicate
that a field is a data-time field. Due to backwards compatibility it
can't use the term data or time to trigger that use, as existing
applications use that and expect a different result, based on published
and promised
On 8/11/19 4:21 PM, Thomas Kurz wrote:
>> I do understand the value of having date/time types in SQLite, but it is not
>> easy to do while retaining backward compatibility. It'll have to wait for
>> SQLite4 or something.
> Actually I do not really understand the point about backward
> I do understand the value of having date/time types in SQLite, but it is not
> easy to do while retaining backward compatibility. It'll have to wait for
> SQLite4 or something.
Actually I do not really understand the point about backward compatibility.
Many very useful suggestions are
27 matches
Mail list logo
