The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

PHPs datetime class can handle a far wider range of dates.
I've not tried checking the limits because it's a pig to work with, and I have no real need for such a wide range of dates... but it's own built-in strtotime functionality does handle both '/' and '-' as date separators, which is useful.

just as a matter of interest does strtotime('19-06-1983') work ok? that's how uk and presumably a number of other countries commonly write dates (day, month, year) but in the u.s. it's month, day, year i'm pretty sure. so how is php supposed to know which you're using? it's impossible. ok in that particular example it can't be the u.s. way because there are not 19 months but that's just lucky. 1983-06-19 is i assume the only safe way to write that.

It seems quite a major issue TBH, not that 2038 is round the corner...

Surely there are applications that would look to use dates as far forward as these.

No?

The switch from 32 bit to 64 bit computers takes care of it automatically since each additional bit doubles the time period that can be covered and so even with the first 30 bits of a 64 bit field still zero a 548 year period is covered. With all 64 bits a period of 588410 million years is covered. That should be enough for the forseeable future.