On Wednesday 24 May 2006 15:18, Brian Menke scribble on about:
Peter, thanks for the detailed info. I will figure out how to get rid of
the UNIQUE key. Somehow that got added. Thanks for the catch. As far as INT
for student id goes, I'm using email because it will be unique, and offers
an easy
On Wednesday 24 May 2006 15:18, Brian Menke scribble on about:
Peter, thanks for the detailed info. I will figure out how to get rid of
the UNIQUE key. Somehow that got added. Thanks for the catch. As far as INT
for student id goes, I'm using email because it will be unique, and offers
an easy
[mailto:[EMAIL PROTECTED]
Sent: Thursday, May 25, 2006 9:13 AM
To: Brian Menke
Cc: [EMAIL PROTECTED]; mysql@lists.mysql.com
Subject: Re: Fun with Dates and Incentives.
Brian,
MySQL's timestamp function is based on the *server*'s timestamp, not
the client's.
-Sheeri
On 5/24/06, Brian Menke [EMAIL
Brawley [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 24, 2006 3:56 PM
To: Brian Menke
Cc: mysql@lists.mysql.com
Subject: Re: Fun with Dates and Incentives.
Brian,
CURRENT_TIMESTAMP gives you time in your server's timezone. UTC_TIMESTAMP
gives GM (universal) time, so dispenses with all timezone
25, 2006 9:13 AM
To: Brian Menke
Cc: [EMAIL PROTECTED]; mysql@lists.mysql.com
Subject: Re: Fun with Dates and Incentives.
Brian,
MySQL's timestamp function is based on the *server*'s timestamp, not
the client's.
-Sheeri
On 5/24/06, Brian Menke [EMAIL PROTECTED] wrote:
Wow, if I read that right
: Thursday, May 25, 2006 9:13 AM
To: Brian Menke
Cc: [EMAIL PROTECTED]; mysql@lists.mysql.com
Subject: Re: Fun with Dates and Incentives.
Brian,
MySQL's timestamp function is based on the *server*'s timestamp, not
the client's.
-Sheeri
On 5/24/06, Brian Menke [EMAIL PROTECTED] wrote:
Wow
Brian,
Just my 2 cents :)
I always try to use an epoch time stamp for anything time related. its
easier to compare times and all the functions are built into mysql to
convert to/from a unix epoch timestamp
select unix_timestamp(NOW());
+---+
| unix_timestamp(NOW()) |
I think doing a sort by date with limit 10 should get you the first
ten. I believe the now() function uses the server time, so no need to
do date/time calcs really.
Good luck,
Jason
Brian Menke wrote:
I'm hoping for some general advice on an approach for the following
scenario:
I have
Brian
Re your schema,
--it's redundant to define PRIMARY and UNIQUE keys on the same column,
--why not an INT student id?
--what if two (eg married) students share an email account?
--comparing datetimes across multiple time zones will be simpler if
you
set
Brawley [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 24, 2006 1:31 PM
To: Brian Menke
Cc: mysql@lists.mysql.com
Subject: Re: Fun with Dates and Incentives.
Brian
Re your schema,
--it's redundant to define PRIMARY and UNIQUE keys on the same column,
--why not an INT student id?
--what if two
Brian,
Somehow the server ate my response...
Re your schema,
--it's redundant to define PRIMARY and UNIQUE keys on the same column,
--why not an INT student id?
--what if two (eg married) students share an email account?
--comparing datetimes across multiple time zones will be simpler if
:[EMAIL PROTECTED]]
Sent: Wednesday, May
24, 2006 1:31
PM
To: Brian Menke
Cc:
mysql@lists.mysql.com
Subject: Re: Fun with
Dates and
Incentives.
Brian
Re your schema,
--it's redundant to define PRIMARY and UNIQUE keys on the same column,
--why not an INT student id?
--what
PROTECTED]
Sent: Wednesday, May 24, 2006 1:31 PM
To: Brian Menke
Cc: mysql@lists.mysql.com
Subject: Re: Fun with Dates and Incentives.
Brian
Re your schema,
--it's redundant to define PRIMARY and UNIQUE keys on the same column,
--why not an INT student id?
--what if two (eg married
13 matches
Mail list logo
