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.
--
http://alt.textdrive.com/nan
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
> loca
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). W
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 times.
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 implemen
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
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
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.
>
..
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 criteri
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 t
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
> fo
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 r
s@sqlite.org
> Subject: Re: [sqlite] CURRENT_DATE Behavior
>
>
>
> D. Richard Hipp wrote:
> >
> > CREATE TABLE whatever(
> >
> > timestamp DATE DEFAULT (datetime('now','localtime')),
> > ...
> > );
> >
>
&
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
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
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 initialized to the
>current date
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 decision,
17 matches
Mail list logo