Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Page 1 of 2 12 LastLast
Results 1 to 15 of 28
  1. #1
    Senior Coder doubledee's Avatar
    Join Date
    Mar 2011
    Location
    Arizona
    Posts
    1,108
    Thanks
    27
    Thanked 0 Times in 0 Posts

    Returned Value: Date or String

    Is the value returned from this Function that I wrote a "Date" or a "String"?

    Code:
    	function getDateTimeMicroTime(){
    		/**
    		 * Create Date-Timestamp with Micro-Seconds.
    		 *
    		 */
    		 
    		list($microSec, $timeStamp) = explode(" ", microtime());
    
    		return (date('omdHis', $timeStamp) . substr($microSec, 1));
    
    		//Ex: 20120721122038.820
    
    	}

    After looking at this old code, I'd say that it is actually a "String"...

    What do you think?

    Sincerely,


    Debbie

  • #2
    Senior Coder Dormilich's Avatar
    Join Date
    Jan 2010
    Location
    Behind the Wall
    Posts
    3,340
    Thanks
    13
    Thanked 349 Times in 345 Posts
    since you do string concatenation, it must be a string. (even if either function wouldn’t return a string (which could be looked up in the manual)). and AFAIK there is no Date class in PHP.
    The computer is always right. The computer is always right. The computer is always right. Take it from someone who has programmed for over ten years: not once has the computational mechanism of the machine malfunctioned.
    André Behrens, NY Times Software Developer

  • #3
    Senior Coder doubledee's Avatar
    Join Date
    Mar 2011
    Location
    Arizona
    Posts
    1,108
    Thanks
    27
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by Dormilich View Post
    since you do string concatenation, it must be a string. (even if either function wouldn’t return a string (which could be looked up in the manual)). and AFAIK there is no Date class in PHP.
    But the reason I am asking this, is that there *is* a "Date" data-type with Prepared Statements, and I have the return value from this function marked as a "d" and after reviewing my code it seems it should be an "s".

    Running things with a "d" has caused no issues, but I wasn't sure if I should change things or not.

    See?

    Sincerely,


    Debbie

  • #4
    Senior Coder Dormilich's Avatar
    Join Date
    Jan 2010
    Location
    Behind the Wall
    Posts
    3,340
    Thanks
    13
    Thanked 349 Times in 345 Posts
    if you’re talking about MySQLi Statement data type identifyers (->bind_param()), "d" stands for "double", not for "date".

    for the MySQL DB I know that dates are usually passed as strings (YYYY-MM-DD HH:MM:SS) (ref.)
    The computer is always right. The computer is always right. The computer is always right. Take it from someone who has programmed for over ten years: not once has the computational mechanism of the machine malfunctioned.
    André Behrens, NY Times Software Developer

  • #5
    God Emperor Fou-Lu's Avatar
    Join Date
    Sep 2002
    Location
    Saskatoon, Saskatchewan
    Posts
    16,994
    Thanks
    4
    Thanked 2,662 Times in 2,631 Posts
    There isnt' a date datatype in PHP. There's a DateTime datatype, which, like the strtotime can interpret a string representation of a date, which is usually what a Date datatype is formatted as.

    There is no date datatype in PHP at all. Even the dateTime isn't what you'd use with SQL code; SQL code is designed to accept a string as its Date datatypes. It stores them in an entirely different manner than the representation of it though, so the Date types in MySQL for example are really more useful to the engine itself allowing to use sorting and comparisons which strings cannot.
    'd' (which cannot be a 'returned' value in a PHP prepared statement, only the bound type), represents 'double' datatype. I don't see a date bind for the PDO either, but I'm not surprised that neither exist in PHP. PHP will handle the results as a string, so if you have a stored procedure that accepts / returns a Date type, than PHP will interpret the string in and out.

    So yeah, if you mean you are providing a prepared statement or a stored procedure with a date in PHP, use a string representation of it. DateTime is ideal for this since you can format it only when you need it and still keep carrying the object around instead. You could rigorously test though, I don't know what MySQL is actually storing the date datatypes as, but if I had to guess it is a numerical type. Problem is that PHP may be limited to only 32-bit signed representation, so you couldn't represent numbers beyond January 19, 2038.
    PHP Code:
    header('HTTP/1.1 420 Enhance Your Calm'); 
    Been gone for a few months, and haven't programmed in that long of a time. Meh, I'll wing it ;)

  • #6
    Senior Coder doubledee's Avatar
    Join Date
    Mar 2011
    Location
    Arizona
    Posts
    1,108
    Thanks
    27
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by Dormilich View Post
    if you’re talking about MySQLi Statement data type identifyers (->bind_param()), "d" stands for "double", not for "date".

    for the MySQL DB I know that dates are usually passed as strings (YYYY-MM-DD HH:MM:SS) (ref.)
    Oops!!

    I got that mixed up!!

    http://www.php.net/manual/en/mysqli-stmt.bind-param.php


    So, with that being said, it looks like I *was* correct in chosing "d" in the past, because I do NOT have an Integer.

    Thanks,


    Debbie

  • #7
    Senior Coder djm0219's Avatar
    Join Date
    Aug 2003
    Location
    Wake Forest, North Carolina
    Posts
    1,303
    Thanks
    4
    Thanked 204 Times in 201 Posts
    Quote Originally Posted by doubledee View Post
    So, with that being said, it looks like I *was* correct in chosing "d" in the past, because I do NOT have an Integer.
    You do not have a double either so a 'd' is not correct for your date. It should be a string on the bind.
    Dave .... HostMonster for all of your hosting needs

  • #8
    Senior Coder doubledee's Avatar
    Join Date
    Mar 2011
    Location
    Arizona
    Posts
    1,108
    Thanks
    27
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by djm0219 View Post
    You do not have a double either so a 'd' is not correct for your date. It should be a string on the bind.
    Does the "data-type" designation for Prepared Statements describe...

    a.) The Data-Type of the PHP value to be handled by the query

    b.) The Data-Type of the MySQL field to accept the PHP value


    Because my function is concatenating two values...
    PHP Code:
        $dateTimeMicroTime = (date('omdHis'$timeStamp) . substr($microSec1)); 
    ...I guess that makes $dateTimeMicroTime a "String" in PHP, right?


    But in my "visitorLog" table, the created_on field is a "Decimal(17, 3)" data-type.


    So what is the proper Data-Type to use in my Prepared Statement?

    "d"

    or

    "s"


    Originally, I chose "d" because while technically the value from my function is a "string", it will get converted to a "(double) decimal" when it gets stuck in the database...

    Sincerely,


    Debbie

  • #9
    Senior Coder Dormilich's Avatar
    Join Date
    Jan 2010
    Location
    Behind the Wall
    Posts
    3,340
    Thanks
    13
    Thanked 349 Times in 345 Posts
    Quote Originally Posted by doubledee View Post
    Originally, I chose "d" because while technically the value from my function is a "string", it will get converted to a "(double) decimal" when it gets stuck in the database...
    nope. DECIMAL and DOUBLE are two very different data types in SQL (one is an exact value, while the other is only an approximate value (cf. floating point arithmetics)
    The computer is always right. The computer is always right. The computer is always right. Take it from someone who has programmed for over ten years: not once has the computational mechanism of the machine malfunctioned.
    André Behrens, NY Times Software Developer

  • #10
    God Emperor Fou-Lu's Avatar
    Join Date
    Sep 2002
    Location
    Saskatoon, Saskatchewan
    Posts
    16,994
    Thanks
    4
    Thanked 2,662 Times in 2,631 Posts
    Concatenated or not, this would still return a string:
    PHP Code:
    $dateTimeMicroTime = (date('omdHis'$timeStamp) . substr($microSec1)); 
    Doesn't matter that every property is numeric, date will always return a string OR false.

    Decimal 17,3 doesn't make any sense to me as to why you've used that for a date/time property. What is this supposed to represent; time typically only has a double component when working with tenths of seconds. DateTime, timestamp or integer would make sense to me.

    PHP wise, decimal and double are both floats, the precision is a mechanism in the dbms. PHP is clueless when it comes to the difference and worse yet is that we cannot explicitly create by datatype, only cast to datatype.
    PHP Code:
    header('HTTP/1.1 420 Enhance Your Calm'); 
    Been gone for a few months, and haven't programmed in that long of a time. Meh, I'll wing it ;)

  • #11
    Senior Coder doubledee's Avatar
    Join Date
    Mar 2011
    Location
    Arizona
    Posts
    1,108
    Thanks
    27
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by Fou-Lu View Post
    Concatenated or not, this would still return a string:
    PHP Code:
    $dateTimeMicroTime = (date('omdHis'$timeStamp) . substr($microSec1)); 
    Doesn't matter that every property is numeric, date will always return a string OR false.
    I get that, but above I asked if the "d" and "s" represent the PHP variable or if they represent the data-type in MySQL...

    If I am matching against $dateTimeMicroTime, then I'd choose "s"

    But if I'm matching against DECIMAL(17,3), then I would think I'd want "d"


    So which is it?



    Quote Originally Posted by Fou-Lu View Post
    Decimal 17,3 doesn't make any sense to me as to why you've used that for a date/time property. What is this supposed to represent; time typically only has a double component when working with tenths of seconds. DateTime, timestamp or integer would make sense to me.
    Maybe there is a better way to have done this, but I chose the approach that I did, because I wanted greater precision than a standard DateTime field would offer me.

    I am working with a "visitorLog" table, and I wanted a way to see if one or more Members or Anonymous Visitors were really 'slamming" a Profile.

    If I just used DateTime, I could have a dozen entries with all the same timestamp.

    By creating what I did, I have a way to see that the same stalker slammed DoubleDee's profile on...
    Code:
    $dateTimeMicroTime		Read
    --------------------		------------------------
    20120721122038.820		2012-07-21 12:20:38.820
    20120721122038.821		2012-07-21 12:20:38.821
    20120721122038.822		2012-07-21 12:20:38.822
    20120721122038.823		2012-07-21 12:20:38.823
    20120721122038.824		2012-07-21 12:20:38.824

    To me this is very easy to follow...

    Sincerely,


    Debbie

  • #12
    Senior Coder Dormilich's Avatar
    Join Date
    Jan 2010
    Location
    Behind the Wall
    Posts
    3,340
    Thanks
    13
    Thanked 349 Times in 345 Posts
    Quote Originally Posted by doubledee View Post
    Maybe there is a better way to have done this, but I chose the approach that I did, because I wanted greater precision than a standard DateTime field would offer me.
    MySQL supports microseconds in DATETIME/TIME/TIMESTAMP fields since 5.6.4
    The computer is always right. The computer is always right. The computer is always right. Take it from someone who has programmed for over ten years: not once has the computational mechanism of the machine malfunctioned.
    André Behrens, NY Times Software Developer

  • #13
    Senior Coder doubledee's Avatar
    Join Date
    Mar 2011
    Location
    Arizona
    Posts
    1,108
    Thanks
    27
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by Dormilich View Post
    MySQL supports microseconds in DATETIME/TIME/TIMESTAMP fields since 5.6.4
    I didn't have MySQL v5.6.4 when I wrote this function last year!

    (And I still don't have it on this old MacBook.)

    Guess I could update things, but what I have should be fine for v2.0


    Just out of curiosity... How hard would it be to convert what I have to this "new" format later on?

    I just hate having to keep changing and improving my code, because every time I do, it postpones me going live...

    Sincerely,



    Debbie

    P.S. Just checked and MAMP v2.2 only has MySQL 5.5.33, so this will definitely have to wait...
    Last edited by doubledee; 10-28-2013 at 07:27 PM.

  • #14
    God Emperor Fou-Lu's Avatar
    Join Date
    Sep 2002
    Location
    Saskatoon, Saskatchewan
    Posts
    16,994
    Thanks
    4
    Thanked 2,662 Times in 2,631 Posts
    I'm sorry, you care about tenths of a second? To what end?
    PHP Code:
    header('HTTP/1.1 420 Enhance Your Calm'); 
    Been gone for a few months, and haven't programmed in that long of a time. Meh, I'll wing it ;)

  • #15
    Senior Coder Dormilich's Avatar
    Join Date
    Jan 2010
    Location
    Behind the Wall
    Posts
    3,340
    Thanks
    13
    Thanked 349 Times in 345 Posts
    Quote Originally Posted by doubledee View Post
    Just out of curiosity... How hard would it be to convert what I have to this "new" format later on?
    it depends ... if you were to use MySQL’s possibilities (e.g. NOW(3) for time with milliseconds), a lot of PHP code would become superfluous.
    The computer is always right. The computer is always right. The computer is always right. Take it from someone who has programmed for over ten years: not once has the computational mechanism of the machine malfunctioned.
    André Behrens, NY Times Software Developer


  •  
    Page 1 of 2 12 LastLast

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •