> Um...how do I go to the page that describes the date-time information
> without just 'knowing' it's there? For example, there seems to be no
> path to http://www.sqlite.org/lang_datefunc.html from
> http://.sqlite.org.
I used Google personally. "sqlite date functions"
John
On Thu, 29 Oct 2009 17:25:34 -0400
Pavel Ivanov wrote:
> > For example, there seems to be no
> > path to http://www.sqlite.org/lang_datefunc.html from
> > http://.sqlite.org.
>
> Go to Documentation -> SQL Syntax -> date and time functions.
>
> Pavel
>
Uh...RTFM? Thanks!
Ted
On Thu, Oct 29, 2009 at 05:21:29PM -0400, Ted Rolle scratched on the wall:
> I'm learning so much from this discussion!
> I've come to believe that late (lazy) typing is a Good Thing(tm).
>
> Um...how do I go to the page that describes the date-time information
> without just 'knowing' it's there?
> For example, there seems to be no
> path to http://www.sqlite.org/lang_datefunc.html from
> http://.sqlite.org.
Go to Documentation -> SQL Syntax -> date and time functions.
Pavel
On Thu, Oct 29, 2009 at 5:21 PM, Ted Rolle wrote:
> I'm learning so much from this discussion!
> I've come to
I'm learning so much from this discussion!
I've come to believe that late (lazy) typing is a Good Thing(tm).
Um...how do I go to the page that describes the date-time information
without just 'knowing' it's there? For example, there seems to be no
path to http://www.sqlite.org/lang_datefunc.html
On Thu, Oct 29, 2009 at 03:21:13PM -0500, Nicolas Williams scratched on the
wall:
> On Wed, Oct 28, 2009 at 07:11:29PM +, O'Neill, Owen wrote:
> > I must agree with other posters that the lack of an exposed timestamp
> > type does feel like something of a gap.
>
> Given the rather large numb
> > I must agree with other posters that the lack of an exposed
timestamp
> > type does feel like something of a gap.
>
> Given the rather large number of reasonable ways to represent
> timestamps, I have to disagree. I'd rather have the freedom to use
> whichever representation is best for my n
On Wed, Oct 28, 2009 at 07:11:29PM +, O'Neill, Owen wrote:
> You can get close if you put some check constraints on the columns.
This is key: you can get the benefits of static and dynamic data typing.
> I must agree with other posters that the lack of an exposed timestamp
> type does feel li
Am 29.10.2009 um 14:31 schrieb Simon Slavin:
>
> On 29 Oct 2009, at 9:36am, John Crenshaw wrote:
>
>>> Consider the case of an application using an SQLite database to
>>> store
>>> its settings (like the Windows registry, but portable). The dynamic
>>> type system is great for this.
>>>
>>> CR
On 29 Oct 2009, at 9:36am, John Crenshaw wrote:
>> Consider the case of an application using an SQLite database to store
>> its settings (like the Windows registry, but portable). The dynamic
>> type system is great for this.
>>
>> CREATE TABLE Settings (Name TEXT PRIMARY KEY, Value BLOB);
>>
>>
>>> *if* you know that the number *is* a date.
>>>
>>
>> If the column has a type of timestamp, it should be safe to always
>> assume that it IS a date.
>sqlite> CREATE TABLE t1 (StartTime TIMESTAMP, Duration REAL);
>sqlite> CREATE TABLE t2 AS SELECT StartTime, StartTime + Duration /
>86400.0
John Crenshaw wrote:
>> *if* you know that the number *is* a date.
>>
>
> If the column has a type of timestamp, it should be safe to always
> assume that it IS a date.
sqlite> CREATE TABLE t1 (StartTime TIMESTAMP, Duration REAL);
sqlite> CREATE TABLE t2 AS SELECT StartTime, StartTime + Durati
urse. They should have been mentioned in the
documentation.
John
-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Dan Bishop
Sent: Thursday, October 29, 2009 3:15 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlit
John Crenshaw wrote:
> Strings have a number of other disadvantages in this case. They take
> more computations to compare, they take time to parse when you read
> them, and they take longer to build when you insert them. Generally,
> storing dates as a number of some sort is ideal.
>
I do agree
n of SQLite Database
Subject: Re: [sqlite] Late data typing. Am I missing something?
John Crenshaw wrote:
> SQLite has plenty of date editing routines. Dates are stored in a
double
> as a Julian date.
Well, that's one way of doing it. I store them as strings because I
wanted a human-re
Jay A. Kreibich wrote:
>> -Original Message-
>> From: sqlite-users-boun...@sqlite.org
>> [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of O'Neill, Owen
>> Sent: Wednesday, October 28, 2009 3:11 PM
>> To: General Discussion of SQLite Database
>&g
John Crenshaw wrote:
> SQLite has plenty of date editing routines. Dates are stored in a double
> as a Julian date.
Well, that's one way of doing it. I store them as strings because I
wanted a human-readable format. The downside is that this requires 19
bytes instead of 8. I wish SQLite could
> -Original Message-
> From: sqlite-users-boun...@sqlite.org
> [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of O'Neill, Owen
> Sent: Wednesday, October 28, 2009 3:11 PM
> To: General Discussion of SQLite Database
> Subject: Re: [sqlite] Late data typing.
Owen
Sent: Wednesday, October 28, 2009 3:11 PM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] Late data typing. Am I missing something?
You can get close if you put some check constraints on the columns.
I must agree with other posters that the lack of an exposed timestamp
type does
Behalf Of Ted Rolle
Sent: Wednesday, October 28, 2009 5:57 PM
To: sqlite-users
Subject: [sqlite] Late data typing. Am I missing something?
Doesn't dynamic data typing lead to bad data?
And proliferation of home-grown editing routines?
It seems that a strict data typing at column definition time
tore the dates differently, or you could store the
timezone separately.
John
-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Ted Rolle
Sent: Wednesday, October 28, 2009 1:57 PM
To: sqlite-users
Subject: [sqlite] Late data typ
On 28 Oct 2009, at 5:57pm, Ted Rolle wrote:
> Doesn't dynamic data typing lead to bad data?
> And proliferation of home-grown editing routines?
True in an application which interacts with a user. Not true in a
database backend. SQLite does not at any time interact with a user:
it does not
Ted Rolle wrote:
> Doesn't dynamic data typing lead to bad data?
No. Buggy programs lead to bad data.
> It seems that a strict data typing at column definition time would be
> MUCH better. For instance, date-editing routines...
There is no shortage of database systems featuring strict typing.
Doesn't dynamic data typing lead to bad data?
And proliferation of home-grown editing routines?
It seems that a strict data typing at column definition time would be
MUCH better. For instance, date-editing routines...
Ted
___
sqlite-users mailing list
s
24 matches
Mail list logo