reading dates befor UNIX epoch reliably

sfullman

UNIX started I think 12/31/1969.

strtotime('Jan 25th, 1985') works fine.

But from my experience reading dates before that is risky, for example:

echo strtotime('Jan 1, 1950'); // -631036800
echo strtotime('Jan 1, 1920'); // -1577808000
echo strtotime('Jan 1, 1900'); // 2086007296 !! yuck

Is there any reliable php way to read dates all the way from say:

May 5th, 969

through

June 1st, 2405
???

Obviously I'm only going to be concerned about factoring in the TIME (hours, minutes, seconds) on dates between about the year 1800 and into the future, but it'd be nice to be assured whatever I entered was reliable.

BTW I really don't like UNIX time, think 20040514172200 (current time here) is a much better system, after all it goes to the year 10,000.

Cheers and Happy Weekend,
Sam

xanas3712

I think, and I'm not really certain with php but I've had a similar problem in nwn, that the problem you are running into has nothing to do with unix timestamps but the maximum size of an integer. I'm going to guess in php that we are working with the standard 32 bit integer which would mean the maximum possible value is something like
2147483648 with the first bit used to set the value to negative or positive (I think, it's been awhile since I've researched this).

Anyhow, so because of time being measured in seconds unless you are using a 64 bit integer or something you are going to run into problems like this one. And, I'm sure there may be issues with going backwards in the first place (I'm not sure).

freebie

Are you using MySQL?
If so, you might consider doing all of the date/time conversions directly with MySQL functions rather than PHP. MySQL has a number of date/time related functions, and has a much simpler date/time format, simply storing it as YYYY-MM-DD HH:MM:SS

xanas3712

yeah, and I think mysql can handle higher than 32 bit math if you want to do some kind of conversion of the timestamp to use something based on minutes instead of seconds (giving you 60 times the range of unixtimestamp within php's 32 bits)...

Should have thought of that myself.

Weedpacket

If you're just storing dates, and don't need second-resolution accuracy, consider storing dates as Julian days instead: instead of counting seconds since 1970-01-01 00:00:00, you count days since a certain date in the fifth millennium BC (the reasons for the precise date are too esoteric to go into here).

PHP's [man]Calendar[/man] extension provides this.

sfullman

You guys' answers on this tends to make me think I'll have to do something custom.

first off, I am analyzing form data BEFORE it goes into db, so mysql's functions are really out of the question.

The bottom line is that YYYY-DD-MM HH:MM:SS is good, Unix is a very BAD way of doing it. There needs to be a strtotime_zero() function which would return seconds from 0000-00-00 00:00:00 (around the Time Jesus lived), up to, well 10,000 when lawyers have been successfully exterminated.

Alternately, per weedpacket, it could store the integer part as days, and the time part as a decimal, might help the string length. After all, about 63,072,000,000 seconds have elapsed since Jesus was a lad.

If anyone knows of such a function, that would close the case.

Cheers :-)
Sam