Re: [sqlite] CURRENT_DATE Behavior

2008-10-22 Thread Petite Abeille
On Oct 21, 2008, at 10:44 PM, jonwood wrote: > Given some of the comments here, one might wonder how those poor MS > SQL Server > folks are able to get anything working at all. ;-) Good point. Usually, "they" don't have anything working at all :)) Cheers, PA. --

Re: [sqlite] CURRENT_DATE Behavior

2008-10-22 Thread jonwood
P Kishor-3 wrote: > > 1. I don't fully understand how to convert UTC to local time? > 2. on a Website > For reasons I don't understand, you split one question in half and called it two questions. P Kishor-3 wrote: > > b. On the other hand, if you want to display on the web page, time >

Re: [sqlite] CURRENT_DATE Behavior

2008-10-22 Thread Scott Baker
On 10/21/2008 05:23 AM, Doug wrote: > In an effort to share some hard-won insight: > > I used to store local times in the database, but it's a bad idea and I got > bit. Think about what gets stored: A number of seconds/nanoseconds/whatever > from some time in the past (Jan 1, 1970 for example).

Re: [sqlite] CURRENT_DATE Behavior

2008-10-22 Thread John Stanton
jonwood wrote: > > cmartin-2 wrote: > >>I suspect it is quite common, e.g., web apps built on SQLServer backends >>are quite likely to use UTC. At any rate, it is definitely a design >>decision, if one expects that local times will always work in all >>scenarios, but all means use local

Re: [sqlite] CURRENT_DATE Behavior

2008-10-22 Thread P Kishor
On 10/22/08, jonwood <[EMAIL PROTECTED]> wrote: > > > P Kishor-3 wrote: > > > > I thought it was very clearly indicated in one of the answers in this > > thread on how to do that. Here it is again... > > > > datetime('now', 'localtime') > > > > > Yes, that was the answer. And it was

Re: [sqlite] CURRENT_DATE Behavior

2008-10-22 Thread jonwood
P Kishor-3 wrote: > > I thought it was very clearly indicated in one of the answers in this > thread on how to do that. Here it is again... > > datetime('now', 'localtime') > Yes, that was the answer. And it was implemented in my application within moments of being posted. The discussion has

Re: [sqlite] CURRENT_DATE Behavior

2008-10-22 Thread P Kishor
On 10/22/08, jonwood <[EMAIL PROTECTED]> wrote: > > > cmartin-2 wrote: > > > > I suspect it is quite common, e.g., web apps built on SQLServer backends > > are quite likely to use UTC. At any rate, it is definitely a design > > decision, if one expects that local times will always work in all

Re: [sqlite] CURRENT_DATE Behavior

2008-10-22 Thread MikeW
MikeW <[EMAIL PROTECTED]> writes: > > jonwood <[EMAIL PROTECTED]> writes: > >> Greetings, >> ... >> Is there ANY way to override this behaviour? Or must I simply initialize all >> such fields explicitly if I would like to set it to the current date in my >> particular time zone? >> >> Thanks. >

Re: [sqlite] CURRENT_DATE Behavior

2008-10-21 Thread jonwood
cmartin-2 wrote: > > I suspect it is quite common, e.g., web apps built on SQLServer backends > are quite likely to use UTC. At any rate, it is definitely a design > decision, if one expects that local times will always work in all > scenarios, but all means use local times. If design

Re: [sqlite] CURRENT_DATE Behavior

2008-10-21 Thread cmartin
On Tue, 21 Oct 2008, jonwood wrote: > mikewhit wrote: >> >> Using UTC in the DB stops you going mad when something happens >> on the DST changeover (localtime hours vanish, or happen twice), >> or you have systems running in or across different countries. >> >> It also means you can subtract two

Re: [sqlite] CURRENT_DATE Behavior

2008-10-21 Thread jonwood
mikewhit wrote: > > Using UTC in the DB stops you going mad when something happens > on the DST changeover (localtime hours vanish, or happen twice), > or you have systems running in or across different countries. > > It also means you can subtract two times and always get the right answer >

Re: [sqlite] CURRENT_DATE Behavior

2008-10-21 Thread MikeW
jonwood <[EMAIL PROTECTED]> writes: > > > Greetings, > > Okay, I understand that the designer of SQLite felt it was important that > fields with a default value of CURRENT_DATE should be initialized to the > current date in a DIFFERENT time zone. Setting aside for now that I've read > all the

Re: [sqlite] CURRENT_DATE Behavior

2008-10-21 Thread Doug
bject: Re: [sqlite] CURRENT_DATE Behavior > > > > D. Richard Hipp wrote: > > > > CREATE TABLE whatever( > > > > timestamp DATE DEFAULT (datetime('now','localtime')), > > ... > > ); > > > > Really? I can do that? Great! >

Re: [sqlite] CURRENT_DATE Behavior

2008-10-20 Thread jonwood
D. Richard Hipp wrote: > > CREATE TABLE whatever( > > timestamp DATE DEFAULT (datetime('now','localtime')), > ... > ); > Really? I can do that? Great! Thanks! -- View this message in context: http://www.nabble.com/CURRENT_DATE-Behavior-tp20075044p20082173.html Sent from

Re: [sqlite] CURRENT_DATE Behavior

2008-10-20 Thread D. Richard Hipp
On Oct 20, 2008, at 1:46 PM, jonwood wrote: > > Greetings, > > Okay, I understand that the designer of SQLite felt it was important > that > fields with a default value of CURRENT_DATE should be initialized to > the > current date in a DIFFERENT time zone. Setting aside for now that > I've

Re: [sqlite] CURRENT_DATE Behavior

2008-10-20 Thread Kees Nuyt
On Mon, 20 Oct 2008 10:46:41 -0700 (PDT), jonwood <[EMAIL PROTECTED]> wrote in General Discussion of SQLite Database : > >Greetings, > >Okay, I understand that the designer of SQLite felt it was important that >fields with a default value of CURRENT_DATE should be

[sqlite] CURRENT_DATE Behavior

2008-10-20 Thread jonwood
Greetings, Okay, I understand that the designer of SQLite felt it was important that fields with a default value of CURRENT_DATE should be initialized to the current date in a DIFFERENT time zone. Setting aside for now that I've read all the reasons for this and am very much against the