How to determine 5 seconds instead of 24 hours using timestamp

[therocker]

Hello, I'm trying to figure out how much is 5 seconds in time stamp.

 

I know that this is 24 hours.

<?php
$timestamp = 1391021444;
if($timestamp >= (time() - 60*60*24)) {
echo "Less than 24 hours";
} else {
echo "More than 24 hours";
}
?>

But I want to try 5 seconds or maybe 10 seconds.

[adam_bray]

<?php

$timestamp = 1391021444;

if($timestamp >= (time() - 5)) {

echo "Less than 5 seconds";

} else {

echo "More than 5 seconds";

}

?>

 

[taquitosensei]

time is the number of seconds since January 1 1970

 

so just compare it.

if(($timestamp2-$timestamp1) < 5) { 
  echo "Less than 5 seconds";
} else { 
  echo "More than 5 seconds";
}

  On 1/29/2014 at 5:03 PM, therocker said:

 

Hello, I'm trying to figure out how much is 5 seconds in time stamp.

 

I know that this is 24 hours.

<?php
$timestamp = 1391021444;
if($timestamp >= (time() - 60*60*24)) {
echo "Less than 24 hours";
} else {
echo "More than 24 hours";
}
?>

But I want to try 5 seconds or maybe 10 seconds.

[therocker]

Thanks adam_bray, that solved it.

taquitosensei, comparing it like this?

<?php
$timestamp1 = $row['timestamp'];
$timestamp2 = time();
if(($timestamp2-$timestamp1) < 5) { 
  echo "Less than 5 seconds";
} else { 
  echo "More than 5 seconds";
}
?>

[taquitosensei]

exactly like that  which is why you did the 60*60*24 to get hours.   60 seconds,60 minutes,24 hours

  On 1/29/2014 at 5:15 PM, therocker said:

 

Thanks adam_bray, that solved it.

taquitosensei, comparing it like this?

<?php
$timestamp1 = $row['timestamp'];
$timestamp2 = time();
if(($timestamp2-$timestamp1) < 5) { 
  echo "Less than 5 seconds";
} else { 
  echo "More than 5 seconds";
}
?>

[therocker]

  On 1/30/2014 at 2:18 PM, taquitosensei said:

exactly like that  which is why you did the 60*60*24 to get hours.   60 seconds,60 minutes,24 hours

Ok thanks. Now it starts to make sense. I don't like to use the date one because it's a bit weird. I typically use timestamps because you can customize the date and time and stuff.

The structure of the date one is a bit weird too. It's like year-date-month-hours-minutes-seconds. The format of that already throws people off. When you use timestamp, you can basically specify a specific thing that you want whether it'd be just the year itself or the date itself. It's easier that way.

 

But yeah. I was thinking 60*60*5, but then I thought 5 should equal 5 hours because 24 equals 24 hours. So I had to ask here to clarify how to properly stamp it out. Now I know how it's done.

[Psycho]

You should not store datetime values as a PHP timestamp in your database because you think the database timestamps in the format "YYYY-MM-DD HH:MM:SS" look weird. The database has a lot of powerful functions for working with date/time fields. By storing a numeric timestamp you make it difficult to impossible to use those functions. The data is not stored for human consumption. There are many methods to convert the time however you wish. For example, if you do need to convert that DB timestamp

 

I don't know what you are trying to do in this code. But, if you wanted to only return records that were less than 5 seconds old you would have to query all of them and then throw out ones you didn't want in PHP logic. That is a waste. Heck, if you just needed to have some text associated with each record based upon whether it was 5 seconds old or not you can do that with your query as well - no PHP code necessary.

[therocker]

  On 1/30/2014 at 10:12 PM, Psycho said:

You should not store datetime values as a PHP timestamp in your database because you think the database timestamps in the format "YYYY-MM-DD HH:MM:SS" look weird. The database has a lot of powerful functions for working with date/time fields. By storing a numeric timestamp you make it difficult to impossible to use those functions. The data is not stored for human consumption. There are many methods to convert the time however you wish. For example, if you do need to convert that DB timestamp I don't know what you are trying to do in this code. But, if you wanted to only return records that were less than 5 seconds old you would have to query all of them and then throw out ones you didn't want in PHP logic. That is a waste. Heck, if you just needed to have some text associated with each record based upon whether it was 5 seconds old or not you can do that with your query as well - no PHP code necessary.

Well yeah. I was only commenting that there are more than 1 way to store time, but a few of them don't look nice. I didn't mean storing datetime as timestamp.

In my code I was trying to call a message that is 5 seconds or less old. The timestamp determines if the message should receive a colored CSS or if it shouldn't. All message are then pushed down that aren't 5 seconds old.

All of the records are displayed, but the records that are fairly new will be given a CSS. That's why I wanted to use 5 seconds.

I'm not saying that the datetime is a bad way. I'm just saying personally I don't like it.

[objnoob]

Datetime is great!  Trying storing an 80 year old's birth date as a timestamp... I bet you can't. Do you know why you can't?

Datetimes typically require more overhead than timestamps. But that's to be expected.

[therocker]

  On 1/30/2014 at 10:45 PM, objnoob said:

Datetime is great!  Trying storing an 80 year old's birth date as a timestamp... I bet you can't. Do you know why you can't?

Datetimes typically require more overhead than timestamps. But that's to be expected.

I don't intend to use timestamp for people's birthdays and there are plenty of ways to store birthdays. The way I'm using timestamp isn't for birthdays. I'm using timestamp for people's posts.

I store birthdays by using 3 different columns. 1 column is varchar and the other 2 is int. For the varchar, it's the actual month.

Let's say someone's birthday is September 31st, 1930.

 

Give them a drop down list and insert September in varchar, 31 in int and 1930 in int. Now let's say what if someone was brilliant and tried to alter that and let's say they tried to insert something like "I hacked your website."

Then validate that in an if statement to check if the value exists in the array and if it doesn't, then don't allow any kind of inserting at all and send them to a different page to warn them.

 

Array could be

 

array('January', 'February', 'March', 'April', 'May', 'June', 'July', 'August', 'September', 'October', 'November', 'December')

 

That's what I would do with Birthdays. But based on my code, I'm using timestamp as a method of allowing people to create posts that will tell people how old the post is. I don't intend on using timestamp as birthdays.

[kicken]

  On 1/31/2014 at 1:35 AM, therocker said:

I store birthdays by using 3 different columns. 1 column is varchar and the other 2 is int. For the varchar, it's the actual month

That's a silly way to store birthdays as well. You should store them in a single DATE column which would be in the YYYY-MM-DD format. You can display the birthday in whatever format you want, or three-input method when asking for the birthdate, but the data itself should be stored in a single column of the DATE type.

 

This way you can use all the aforementioned datetime functions to do things like calculate a persons age or query for upcoming birthdays.

 

As for your post timestamps, those would be better stored as a DATETIME value as well. In addition to allowing the use of the aforementioned datetime functions, it makes the data readable in the event you need to manually query the database for some reason. Say you were debugging a query and the post time is part of the selected columns/conditions, which is easier to read:

 

+--------+---------------------+
| name   | postedWhen          |
+--------+---------------------+
| kicken | 2014-01-30 21:04:24 |
+--------+---------------------+

or

+--------+------------+
| name   | postedWhen |
+--------+------------+
| kicken | 1391133864 |
+--------+------------+

Having the data stored as a datetime would allow you to do your 5-second check right in your query when selecting posts. eg:

SELECT 
   name
   , postedWhen
   , CASE WHEN postedWhen > DATE_SUB(NOW(), INTERVAL 5 SECOND) THEN 1 ELSE 0 END as isNew 
FROM posts

Bottom line is storing the data as a unix timestamp is wrong, and you should change that if at all possible.

[therocker]

  On 1/31/2014 at 2:09 AM, kicken said:

That's a silly way to store birthdays as well. You should store them in a single DATE column which would be in the YYYY-MM-DD format. You can display the birthday in whatever format you want, or three-input method when asking for the birthdate, but the data itself should be stored in a single column of the DATE type.

 

This way you can use all the aforementioned datetime functions to do things like calculate a persons age or query for upcoming birthdays.

 

As for your post timestamps, those would be better stored as a DATETIME value as well. In addition to allowing the use of the aforementioned datetime functions, it makes the data readable in the event you need to manually query the database for some reason. Say you were debugging a query and the post time is part of the selected columns/conditions, which is easier to read:

 

+--------+---------------------+
| name   | postedWhen          |
+--------+---------------------+
| kicken | 2014-01-30 21:04:24 |
+--------+---------------------+

or

+--------+------------+
| name   | postedWhen |
+--------+------------+
| kicken | 1391133864 |
+--------+------------+

Having the data stored as a datetime would allow you to do your 5-second check right in your query when selecting posts. eg:

SELECT 
   name
   , postedWhen
   , CASE WHEN postedWhen > DATE_SUB(NOW(), INTERVAL 5 SECOND) THEN 1 ELSE 0 END as isNew 
FROM posts

Bottom line is storing the data as a unix timestamp is wrong, and you should change that if at all possible.

 

So you're saying when timestamp converted to this it means that it's super harder to read than datetime?

<?php
$timestamp = 1391141472;
echo date('l, F jS, Y', $timestamp);
?>

The output of this gives you "Thursday, January 30th, 2014".

That's hard to read?

 

Let's say you don't feel like going into the database every 10 seconds. Let's say you output this one to what I have and let's say you keep the datetime since you say it's readable.

 

Is

Thursday, January 30th, 2014

more readable than

2014-30-01

What if someone's dyslexic?

 

All in all, it just depends on which one you prefer most. I like timestamp more since it's user friendly to me so I'm just going to keep it that way. You can't command me to change my time because you don't like the way I'm inserting my data.

 

All I commented on was datetime looked weird and that's why I don't use it. I'm not saying "Hey, I'm a fan of timestamp and all those people who uses datetime are stupid."

No, I'm just simply saying that it looks weird so I don't use it.

Not just that. To see a current file with updates what do you normally do?

You would normally have something like this.

style.css

But what if you made a change in that file and only the people who refreshes the page 2 times in a row can see that change?

How about an image? What if someone changed their avatar, will anyone else see the newest one they've uploaded?

And when I say refresh, I'm not talking about hitting that reload button up in your address bar. That won't do a thing. But I mean manually right click and hitting "refresh" or "reload".

 

That's why you should use timestamp to do this.

style.css?<?php echo time(); ?>

That will give you the current updated version of that style. People don't have to refresh the page twice just to see a new style. People don't need to wait until tomorrow to see someone's new avatar. If you add in timestamp, you automatically see it in that second they change it.

 

That is why I use timestamp in my codes and if you guys don't like it. Fine. I'm not going to change my code because you guys don't like it. I'm just asking for help for the 5 seconds and I only commented on why I don't use datetime instead. I didn't say that timestamp was better.

[KevinM1]

Calm down. No one is 'commanding' you to do anything. All we're doing is suggesting a different way of doing things based on our collective experience using the various time formats and functions available. Feel free to ignore that advice if you want. There's no MySQL or PHP police that's going to be sent after you, so there's no need to get defensive about it.

[therocker]

  On 1/31/2014 at 2:55 AM, KevinM1 said:

Calm down. No one is 'commanding' you to do anything. All we're doing is suggesting a different way of doing things based on our collective experience using the various time formats and functions available. Feel free to ignore that advice if you want. There's no MySQL or PHP police that's going to be sent after you, so there's no need to get defensive about it.

Actually..

 

  On 1/31/2014 at 2:09 AM, kicken said:

Bottom line is storing the data as a unix timestamp is wrong, and you should change that if at all possible.

 

It is possible to change to anything since I'm just testing on my localhost, but would I change it because someone said it was wrong?

And I'm not getting defensive. I'm actually stating facts that backup the reason behind me using timestamp.

I honestly don't care which time format you use. Just don't say what kicken said to me.

[kicken]

  On 1/31/2014 at 2:35 AM, therocker said:

So you're saying when timestamp converted to this it means that it's super harder to read than datetime?

<?php
$timestamp = 1391141472;
echo date('l, F jS, Y', $timestamp);
?>

The output of this gives you "Thursday, January 30th, 2014".

That's hard to read?

 

No, but that's also irrelevant to what I was talking about. If you read what I wrote:

  Quote

...it makes the data readable in the event you need to manually query the database for some reason.

Ie, querying the database directly using PHPMyAdmin or the MySQL command line, not with your scripts. When you do that you don't get the chance to format your timestamps with PHP, you just see the raw number. If you use a proper DATETIME column you'd see a human-readable date not some giant number.

 

When it comes to actually outputting the dates on your pages for end users, as has been said before, you are not stuck with the default YYYY-MM-DD HH:mm:ss DATETIME format. You can convert it to whatever format prior to display. Conversely, you can also convert whatever format you want into the YYYY-MM-DD HH:mm:ss format when asking for date/time inputs on your site.

 

 

  On 1/31/2014 at 2:35 AM, therocker said:

All I commented on was datetime looked weird and that's why I don't use it. I'm not saying "Hey, I'm a fan of timestamp and all those people who uses datetime are stupid."

Doing something in an ill-advised way just because the proper way "looks weird" is a poor excuse.

 

  On 1/31/2014 at 2:35 AM, therocker said:

That's why you should use timestamp to do this.

style.css?<?php echo time(); ?>

That will give you the current updated version of that style. People don't have to refresh the page twice just to see a new style.

 

We never said that using a timestamp is always wrong. We said that storing them in your database is wrong. Appending a timestamp to a url is perfectly valid and has absolutely nothing to do with storing a timestamp in a database.

 

That said, if you append the timestamp all the time, you are also destroying any possible caching of the stylesheet, which is also bad. Most of the time your stylesheet isn't going to be constantly changing so there is no point in people downloading a fresh one every time they load the page. By adding the current timestamp on every page load you'll force people to download the stylesheet on every request, wasting time and bandwidth.

 

If you want to add a timestamp to aid with detecting changes, you should add one that only changes when the file changes, such as the file's modification date timestamp as returned by filemtime.

 

  On 1/31/2014 at 2:35 AM, therocker said:

That is why I use timestamp in my codes and if you guys don't like it. Fine. I'm not going to change my code because you guys don't like it.

Then that's your choice, I can't force you to change anything. I said if possible because I realize sometimes something is either out of your control, or you're already so deep in the current design that it's not worth changing. What I said was simply a strong suggestion, not a demand. It's not like I am going to stop helping you (or anyone else) unless you change it, but you'll likely hear the same suggestions in the future if you post other threads involving timestamps stored in your database. Not as a result of some effort to force you to change, but rather just because timestamps are ill-advised and likely we won't remember having already told you before.

 

When I started also stored every date as an INT column with a timestamp in it. It seemed like it was easier to deal with in the PHP code and there is some truth to that. However once I actually took the time to learn the database-provided date functions I saw the value of using proper DATE or DATETIME column types. A lot of what I previously did in PHP was easier to do and more efficiently done in the SQL using the date functions. I rarely have to do much date manipulation in PHP anymore, and for those times it is necessary it is easy to convert a DATETIME value to a timestamp using either the DateTime class or strtotime function.

 

There are many benefits to storing the data in a properly typed column, and the learning curve is fairly minimal.

[objnoob]

  On 1/31/2014 at 5:02 AM, kicken said:

Ie, querying the database directly using PHPMyAdmin or the MySQL command line, not with your scripts. When you do that you don't get the chance to format your timestamps with PHP, you just see the raw number. If you use a proper DATETIME column you'd see a human-readable date not some giant number.

 

it's very [programmer] human-readable for me too! when working with large schemas and large data sets, i've found it's more productive to work outside of php. This format is the most useful to me and easily sortable by eye. after all, it wasn't an accident the Y-m-d H:i:s became the format.