Max Date

NZ_Kiwis

WHat is the biggest date PHP can handle?
Can you make this longer?

Weedpacket

NZ_Kiwis wrote:
WHat is the biggest date PHP can handle?

Depends on whether or not you use the DateTime class. If you don't, on a 32-bit processor, 2038-01-19 03:14:07 UTC. (ref. date Changelog).

Can you make this longer?

Use the DateTime class or a 64-bit system.

NZ_Kiwis

Bugger, what if I can't upgrade and I need a longer date?

Can I make a custom function?

bradgrafelman

Why can't you upgrade? What's the most recent version of PHP you have access to?

As far as the dates... what do you need to do with the dates, and where do they come from? You can have a date of '9999-12-31' or even later on any system, so long as you don't care to actually do any date arithmetic or reformatting and can simply treat the date as a normal string.

Weedpacket

NZ_Kiwis wrote:
Can I make a custom function?

Why bother? I wrote

Weedpacket wrote:
Use the DateTime class or a 64-bit system.

That's "or", not "and".

NZ_Kiwis

My webserver wont allow an upgrade as I paid for what they offer now.
It's a online game with a fake "game date" - it will go passes 2038

I would love to convert it to a time stamp but would live without if needed.

bradgrafelman

So what version of PHP are you using?

Also, is a DBMS (e.g. MySQL) involved at all? If so, why use PHP to handle the dates at all?

NZ_Kiwis

I'm not sure right now, I'm sure it stops at 2038 though.

It will be saved in a mySQL when the game is saved, on a set interval it will increase by one month so as long as that does not drain the server I could add, retrieve and update from there, why?

bradgrafelman

NZ_Kiwis;10993545 wrote:
I'm not sure right now

So you're here asking us about the capabilities of PHP when you don't even know what version of PHP you're working with? Even though a simple call to phpinfo() would answer that immediately? Um... okay. :o

NZ_Kiwis;10993545 wrote:
on a set interval it will increase by one month so as long as that does not drain the server I could add, retrieve and update from there, why?

Why does PHP's date handling capabilities have any relevance, then? MySQL's DATE column type already supports dates up to '9999-12-31' (and as early as '1000-01-01'), and MySQL is perfectly capable of doing date arithmetic as well.

Surely you weren't planning on executing a query to SELECT some date data, fetch it into PHP, do some math on it, then execute a separate query again to UPDATE the database with the new date - all in place of a simple UPDATE query that lets MySQL handle the arithmetic itself... right?

NZ_Kiwis

bradgrafelman;10993546 wrote:
So you're here asking us about the capabilities of PHP when you don't even know what version of PHP you're working with? Even though a simple call to phpinfo() would answer that immediately? Um... okay. :o

I'm at work, I can't run this script and see.

bradgrafelman;10993546 wrote:
Why does PHP's date handling capabilities have any relevance, then? MySQL's DATE column type already supports dates up to '9999-12-31' (and as early as '1000-01-01'), and MySQL is perfectly capable of doing date arithmetic as well.

Surely you weren't planning on executing a query to SELECT some date data, fetch it into PHP, do some math on it, then execute a separate query again to UPDATE the database with the new date - all in place of a simple UPDATE query that lets MySQL handle the arithmetic itself... right?

Yes, why not?

I was going to get game date, update it then save it on exit, what is wrong? What better way should I use?

bradgrafelman

NZ_Kiwis;10993547 wrote:
Yes, why not?

Well for starters, it's inefficient and apparently requires more than what your PHP installation can provide.

NZ_Kiwis;10993547 wrote:
I was going to get game date, update it then save it on exit, what is wrong? What better way should I use?

MySQL has built-in Date and Time Functions. For example, MySQL is perfectly capable of understanding something like:

date_col = date_col + INTERVAL 1 MONTH

Weedpacket

If you do need to do date arithmetic in PHP (such as calculating dates prior to storage) then have a look at the DateTime class. Yes, I know, it's the fourth time I've mentioned it, but maybe if I underlined it and wrote it in blue it might be noticed.

NZ_Kiwis

Yes but with the dateTime class you can only go to 2038 which we already found out was not going to work for me.

If the GameDate updated every, I dunno 15 seconds, would that be much load on my server if I had 500 people playing this game at once?

Update MyGameDate SET MyGameDate = $Date WHERE MyGameID = $ID

bradgrafelman

NZ_Kiwis;10993582 wrote:
Yes but with the dateTime class you can only go to 2038

Says who? (And whoever said that, be sure to tell them they were mistaken. 😉)

The PHP manual certainly has a different opinion; from the man page [man]intro.datetime[/man]:

PHP Manual wrote:
The date and time information is internally stored as an 64-bit number so all imaginable dates (including negative years) are supported. The range is from about 292 billion years in the past to the same in the future.

NZ_Kiwis wrote:
If the GameDate updated every, I dunno 15 seconds, would that be much load on my server if I had 500 people playing this game at once?

Whether or not your server has the necessary resources to keep up at all is something you'd want to do some benchmarking and profiling to determine. However, if we're talking about efficiency, let's compare your method versus my proposed method. You are wanting to:

Execute a query to SELECT the date from all rows in the DB.
Loop through the result set, fetching each row one-by-one from the DB into PHP. For each row, you also:
1. Perform some calculation and/or string manipulation in PHP to update the date.
2. Execute a SQL query to update that row's date value in the DB with the new value from above.

In other words, you're going to execute n+1 SQL queries, where n is the number of rows in the table. In other words, you're up to 4(n+1) SQL queries per hour just to update the time.

My suggestion was to simply:

Execute a query to UPDATE all rows by adding 15 minutes to the rows' previous values, respectively.

That's only 1 query, or 4 queries per hour (regardless of the number of rows in the table).

NZ_Kiwis

bradgrafelman;10993533 wrote:
Says who? (And whoever said that, be sure to tell them they were mistaken. )

The PHP manual certainly has a different opinion; from the man page intro.datetime:

Stated earlier in this thread? or are these different?

Weedpacket;10993533 wrote:
Depends on whether or not you use the DateTime class. If you don't, on a 32-bit processor, 2038-01-19 03:14:07 UTC. (ref. date Changelog).

Use the DateTime class or a 64-bit system.

Whether or not your server has the necessary resources to keep up at all is something you'd want to do some benchmarking and profiling to determine. However, if we're talking about efficiency, let's compare your method versus my proposed method. You are wanting to:
Execute a query to SELECT the date from all rows in the DB.
Loop through the result set, fetching each row one-by-one from the DB into PHP. For each row, you also:
Perform some calculation and/or string manipulation in PHP to update the date.
Execute a SQL query to update that row's date value in the DB with the new value from above.

In other words, you're going to execute n+1 SQL queries, where n is the number of rows in the table. In other words, you're up to 4(n+1) SQL queries per hour just to update the time.

My suggestion was to simply:
Execute a query to UPDATE all rows by adding 15 minutes to the rows' previous values, respectively.

That's only 1 query, or 4 queries per hour (regardless of the number of rows in the table).

I will save the $GameDate when a user saves the game either way.
Do i save it on every cycle? I didn't want to as what if a browser closes, the date would be updated but some other things wouldn't be.

I was going to store this in a variable and save everything every 15 minutes.
I'm a little lost to update you have some many queries anyway, the one a posted only would only update one row

Derokorian

NZ_Kiwis;10993596 wrote:
Says who? (And whoever said that, be sure to tell them they were mistaken. )

The PHP manual certainly has a different opinion; from the man page intro.datetime:
Stated earlier in this thread? or are these different?

Depends on whether or not you use the DateTime class. If you don't, on a 32-bit processor, 2038-01-19 03:14:07 UTC. (ref. date Changelog).

Use the DateTime class or a 64-bit system.

If you DON'T use the datetime class, and are on a 32-bit system you are limited to the year 2038, however if you DO use the date-time class you do not have this limitation as stated in the post you quoted....