:-)
Cheers.
-Dana
> -Original Message-
> From: Jim Sander [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, December 23, 2002 12:58 PM
> Cc: [EMAIL PROTECTED]
> Subject: Re: What, if anything, is wrong with UNIX Epoch time stamps?
> [Was: R E: TimeStamp in MySQL reqd NULL]
>
Csongor Fagyal wrote:
I personally prefer TAI64 time (sub-second precision; see
http://cr.yp.to/libtai/tai64.html). For a comparison of how this
differs from UNIX time, see http://cr.yp.to/proto/utctai.html at the
same site. I'm surprised SQL hasn't been updated to support new time
formats
I personally prefer TAI64 time (sub-second precision; see
http://cr.yp.to/libtai/tai64.html). For a comparison of how this
differs from UNIX time, see http://cr.yp.to/proto/utctai.html at the
same site. I'm surprised SQL hasn't been updated to support new time
formats yet, but oh well.
Well,
> Can anyone share and/or comment about the use of Epoch time,
> especially the hazards?
Using timestamps you can synch all your times with the server via
'now()' and the like. If you use the epoch time on the client side you
might have problems. What those problems are, I couldn't say- but I h
> -Original Message-
> From: Michael T. Babcock [mailto:[EMAIL PROTECTED]]
> Csongor Fagyal wrote:
>
> > Oh and one more thing I am not really sure of: sometimes
> defining the
> > day as 3600*24 or the year as 3600*24*365 is not the best
> idea... just
> > think about leap
: Michael T. Babcock [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, December 23, 2002 10:55 AM
> To: Dana Diederich
> Cc: 'Keith C. Ivey'; [EMAIL PROTECTED]; Akash
> Subject: Re: What, if anything, is wrong with UNIX Epoch time stamps?
> [Was: R E: TimeStamp in
; Sent: Monday, December 23, 2002 10:57 AM
> To: [EMAIL PROTECTED]
> Cc: Dana Diederich; 'Keith C. Ivey'; [EMAIL PROTECTED]; Akash
> Subject: Re: What, if anything, is wrong with UNIX Epoch time stamps?
> [Was: R E: TimeStamp in MySQL reqd NULL]
>
> Csongor
On Monday 23 December 2002 12:41, Akash wrote:
> I want to store NULLS or '0' in a column which is of type
> TimeStamp.
> According to MySQL implementation, if I give the default value of the
> column during table creation as NULL, it will store the current time in the
> timestamp colu
Csongor Fagyal wrote:
Oh and one more thing I am not really sure of: sometimes defining the
day as 3600*24 or the year as 3600*24*365 is not the best idea... just
think about leap years. How do you handle that? And there are some
more "artifacts" in the Gregorian calendar, too...
But MySQL d
Dana Diederich wrote:
Can anyone share and/or comment about the use of Epoch time, especially the
hazards? I'm asking because I want to make sure that I haven't built a
comfortable little box that un-necessarily excludes some useful functions.
I use Epoch time myself, except where I use TIME
Dana Diederich wrote:
This is a related but different question/comment.
In the six or so years of using MySQL, my various teams have never used
anything except an unsigned INT and UNIX Epoch time to record timestamps.
The given is, of course, we have always been a Perl/C/C++/UNIX shop, and we
wi
]]
> Sent: Monday, December 23, 2002 9:16 AM
> To: [EMAIL PROTECTED]
> Cc: Akash
> Subject: Re: TimeStamp in MySQL reqd NULL
>
> On 23 Dec 2002, at 16:11, Akash wrote:
>
> > According to MySQL implementation, if I give the default value of the
>
On 23 Dec 2002, at 16:11, Akash wrote:
> According to MySQL implementation, if I give the default value of the column
> during table creation as NULL, it will store the current time in the
> timestamp column. I do not want this "current time" to be stored in the
> timestamp column. I want it to be
Hi,
I want to store NULLS or '0' in a column which is of type
TimeStamp.
According to MySQL implementation, if I give the default value of the column
during table creation as NULL, it will store the current time in the
timestamp column. I do not want this "current time" to be stored in
14 matches
Mail list logo
