Quick fix for “java.sql.SQLException: Value ‘0000-00-00’ can not be represented as java.sql.Timestamp”

If you ever run across this while fighting with Hibernate, one quick fix is to instruct JDBC to turn the bad date values into NULLs, eg:


Your mileage side-effects may vary.

More excellent Java + J2EE tips (and lots of other stuff in Czech) here.

Diff’ing files over the network

This is a godsend. Wish I had thought about doing this before.

$ diff source/worksforme.php <(ssh -n me@liveserver cat /home/me/source/worksforme.php)

You can also compare files on two remote hosts.

$ diff <(ssh -n me@testserver cat /home/me/source/worksforme.php) <(ssh -n me@clientserver cat /home/me/source/worksforme.php)

Remote access to a Mac from a Windows (Vista) box

If you find that you need to access a Mac from a Windows box, probably you’ll find yourself surfing the specs of a variety of Win32 X-Windows clients. Here are some that I tried:

Cygwin also has an X client, but I didn’t muck around with that.

RealVNC is (I think) the original. I’m guessing that the others are forks of Real, and that either Echo is a fork of Ultra or Ultra a fork of Echo. Tight seems to be a fork of an earlier, simpler version of RealVNC. And, according to their website, is “fully compatible with the standard RFB protocol used in VNC.”

It’s not surprising then that, out of the box, TightVNC is the only client I could get to connect to a Mac from my Vista machine at home. Tight’s refresh/rendering is plenty slow, but gets the job done.

This is Epoch

Literally. I was just alerted to this site here:


As you can see, in less than five days the Epoch time will reach 1234567890.  Ephoch time is, of course, POSIX time, a popular time-keeping method for Unix which is measured in the number of seconds that have passed since the POSIX clock started virtually ticking at midnight on January 1, 1970 (not including leap seconds).

I hereby call on all geeks everywhere to begin immediate global Epoch time party mobilization.   We’re gonna party like it’s 915148800!!

Or, well technically we’re going to party like it’s 915148800 + 319419090 plus or minus some leap seconds.  Which happens to also be this coming Friday the thirteenth.  Which might be unlucky except that it falls before Valentine’s day in the year of the Bull, so…

Er.. Nevermind, just get some booze and spread the word.

Character encoding translation breaks when upgrading WordPress

Recent versions of WordPress like to second-guess the internal and external encodings used by mbstring when assembling data from the database and spitting it out to blog pages.  Probably this works fine for most, but if you have an older database storing text as something other then UTF-8, probably you have a custom chunk of mbstring configuration in an .htaccess file or similar; perhaps like this:

php_value output_buffering 1
php_value output_handler mb_output_handler
php_value mbstring.language Japanese
php_value mbstring.internal_encoding EUC-JP
php_value mbstring.http_input auto
php_value mbstring.http_output SJIS
php_value mbstring.encoding_translation 1

WordPress’s second-guessing will break this, resulting in a bunch of garbled posts. To fix, comment out this chunk of code in wp-settings.php:

 * In most cases the default internal encoding is latin1, which is of no use,
 * since we want to use the mb_ functions for utf-8 strings
if (function_exists('mb_internal_encoding')) {
        if (!@mb_internal_encoding(get_option('blog_charset')))

With this gone, WordPress will stop second-guessing and custom encoding translations should flow through just fine.