It would be funny though to have the first post in your blog dated as your actual birthday, the very beginning of it all.
Except in my case this isn’t possible 🙁 -> 1963 (sigh…)
No, I wasn’t blogging in the 1500’s – I was just experimenting. I can change the dates to something equally silly in the future, but for the record this is a feature MT has and WP doesn’t. See http://jemimap.freeshell.org/moveablecolor/ – the month names are in Portuguese, which was as close as I could get to Latin in MT.
Anonymous
Haven’t been around these forums lately, was wondering if anyone else was worried about UNIX epoch. A little while back, I wrote a work-around for WP 1.0 that used and open source library of time calculations (adodb, I think?), and it seemed (on the surface) to work OK. This wasn’t too hard because WP stores the data-time field as a date data type in the DB, so no information is lost! Other tools are *much* harder to hack because they store them as integers – specifically int(10)’s. There were 5 or 6 places that needed modification, most calls went through a common set of time utilities. Not sure if this is still the case.
Why would someone want to do this? Not necessarily in a traditional blog, but I’ve run into historical societies, museums, etc., that want bios and “timelines” that are sortable, searchable and inter-related. With categories, profiles and “blogs”, you can do a lot of cool stuff!
Anonymous
Pepys Diary runs on MT and uses dates from the 17th century, so if they wanted to switch to WP they couldn’t. 🙁
Out of interest is there any limitation on how far in the future you can post?
It should be a very easy hack to translate the output of the date tag.
Anonymous
Here’s the short doc at the top of the adodb code:
PHP native date functions use integer timestamps for computations.
Because of this, dates are restricted to the years 1901-2038 on Unix
and 1970-2038 on Windows due to integer overflow for dates beyond
those years. This library overcomes these limitations by replacing the
native function’s signed integers (normally 32-bits) with PHP floating
point numbers (normally 64-bits).
Dates from 100 A.D. to 3000 A.D. and later
have been tested. The minimum is 100 A.D. as <100 will invoke the
2 => 4 digit year conversion. The maximum is billions of years in the
future, but this is a theoretical limit as the computation of that year
would take too long with the current implementation of adodb_mktime().
————————————————————————————
Technically, the db field itself should port into the WP db from MT. But the time functions, like mktime() are the problem. On 1.0x, I made a few changes to “functions.inc” and “template-functions.inc”, but they got broken out further in 1.2. There’s also some localization decisions you will have to make (like if you enter a date prior to 1884, it really doesn’t make a lot of sense, as GMT was only established in 10/1884 ).
And there are a other years that are affected by when the country in question adopted the Gregorian Calendar (affecting the month list and back/next keys).
If you look at Pepys Diary on the archive page, you’ll see that they list the years as “1659/60” to indicate that in England pre 1752, the new years was in March, dispite other Catholic countries of Europe having standardized on January 1 in 1622.
Just some trivia for the time-weary public! I’m working with another “community freeware” tool right now but I can say that the WP 1.0 was very easy to hack and took only a few hours to change and test.
I wish someone would fix (er… hack) this on WordPress 1.5 to make it display dates before 1969.
I’ve just started creating a WP1.5 blog based on my grandmother’s diaries for 1940 and 1941 and ran into this problem – just wondered whether anyone had … er, fixed this yet? Or could offer me any helpful suggestions?
You can try these instructions (note the use at your own risk disclaimer):
http://wordpress.org/support/topic/27367#post-194153
