Part 2 The Database
Since without shell access we can’t use Horde’s setup (./scripts/setup.php) to do this for us we have to manually set up the database for Horde.

This step depends on your webhosters so i’ll just make it quick:
First create a database with your webhost, then find: hostname (often locahost), username, password, type (often tcp) and databasename for that database.

Now your webhoster probably offers some kind of management frontend (mostly phpmyadmin). There you navigate to your database and select the “SQL” tab.

In the editbox you will find there you have to paste some of the lines from the .sql file provided with Horde that matches your database. I use mysql so i used ./scripts/sql/create.mysql.sql.

Out host already created the database, the user etc. so we only need lines that create tables. In my file this would be lines 52 -> end (look for the first CREATE TABLE statement). Copy&Paste and press Submit. This should have given you no errors and created ~18 tables in your database.

In the next step we will create a basic configuration that allows Horde to run so we can do the rest of the setup from within it.

This experiment will most likely fail because i don’t have shell access and the php installation is probably missing vital modules .. but what else is there to do on a saturday evening

Part1: Horde is f***ing huge!


du -sch .
108M total


I’ll start by making horde a little slimer…
This will give me all the folders with locales other than german or english (cd to horde first)

find -iname ??_?? -type d | grep -v de_DE | grep -v en_US | grep -v en_GB

and this will delete them

find -iname ??_?? -type d | grep -v de_DE | grep -v en_US | grep -v en_GB | xargs rm -r


The same for the “.po” files:

find -iname ??_??.po -type f | grep -v de_DE | grep -v en_US | grep -v en_GB | xargs rm -r



du -sch .
51M total

Half the size, nice :)

An onomatopoeical adjective based on the sound emitted when something is “oh so tasty” (either through hunger or flavorological value) that one gnaws through it without regard to cleanliness or etiquette.

These Prices are in German Marks, which back then was maybe half to two thirds of a dollar (date is in MM/YY form and the comma marks the decimal point, so first entry reads 62 Mark and 3 Pfennig)

07/98: 62,03
08/98: 190,66
09/98: 193,22
10/98: 174,92
11/98: 176,06
12/98: 231,59
01/99: 179,12
02/99: 207,84
03/99: 237,94
04/99: 238,27
05/99: 226,31
06/99: 137,04

Back then you had 56kbit with a modem or 64kbit with ISDN later and you had to make every minute count ;) All of this was to play Ultima Online in the evenings and i was still in school back then … kind of an expensive hobby :)
Comparing this to today’s DSL market really makes you cry ;)
You get 16mbit down 1mbit DSL up for 20 euros flat or even 50mbit down 10mbit up VDSL for 70 euros flat. Kids today have it way to easy! :)

It worked fine, currently I set it to the newest tag, but in future I might switch to the trunk, maybe then finally something breakes that I can then fix ;)

Title is once again inspired by a song I currently like, which was used as the music in this lovely “hooping” video:

If you create a DateTime object like this (in the current stable version of php, 5.2.3):

<?php
$oDateTest = new DateTime("@0", new DateTimeZone(date_default_timezone_get()));
echo "tz: ".$oDateTest->getTimezone()->getName()."\n";
echo "date: ". $oDateTest->format("Y-m-d H:i:s")."\n";
?>

It will be in the default timezone (’Europe/Berlin’ in my case) but say the date is 1970-01-01 00:00. This is wrong. The Unix timestamp “0″ stands for that exact date, but in another timezone: UTC. It should be 01:00 in Berlin.

This bug was reported multiple times, but with sometimes confusing bug reports. But someone had managed to submit a clear bug report with code to reproduce the behaviour (PHP Bug 43003) and the php developers acknowledged the bug and issued a fix that i verified to be (at least) in the following snapshots: php5.2-200803111530 and php5.3-200803111530.

Sadly, this fix is at best “unintuitive”, maybe it even qualifies as “still broken”. The above code gives the following output in these snapshots:

tz: +00:00
date: 1970-01-01 00:00:00

So, the DateTime object now knows that UNIX timestamps always are given in UTC and sets it’s timezone accordingly. But is this what it should do in this case? I - the programmer - clearly stated i wanted the DateTime object to be in my default timezone! Even if i explicitly give the timezone as ‘Europe/Berlin’ during construction, the object’s timezone still is UTC afterwards.

So instead of knowing that i have to manually set the DateTime to UTC, then back to my desired timezone when working with an UNIX timestamp i now have to know that a DateTime will be in UTC after setting it up with a UNIX timestamp. Personally i hate having to know things, IMHO it’s a sign of weak design. The API has to be clear, i don’t give a rat’s backside about the inner workings and struggles of the objects i use.

We went from this:

// FIXME: DateTime issue... needs the conversion to and from UTC...
$oDateTest = new DateTime("@0", new DateTimeZone('UTC'));
$oDateTest->setTimezone(new DateTimeZone("Europe/Berlin"));

To this:

// FIXME: DateTime issue... will always be UTC afterwards...
$oDateTest = new DateTime("@0", new DateTimeZone('Europe/Berlin')); // or UTC, or what/ever....
$oDateTest->setTimezone(new DateTimeZone("Europe/Berlin"));

Is this better or worse?

First somebody sends you this:

Then you watch this as a followup…

After that you watch this related video…

And, just because you’re doing nothing special anyways, you watch this afterwards…

And if you’re like me, always looking for the “real” version of a video before rating/favorting it and reading some comments etc. this just took you an hour ;)