Tollef Fog Heen's blog

A bit surprising, really.

: tfheen@thosu ~ > history 1|awk '{print $2}'|awk 'BEGIN {FS="|"} {print $1}'|sort|uniq -c | sort -nr |head -n 10
  21477 ls
  18170 cd
  10640 ssh
   9257 sudo
   5559 less
   3015 grep
   2407 bzr
   2101 ps
   1980 man
   1980 debuild

For those of you wondering why there is no editor on the list; I use emacs and it's in the 11th place (with 1903 runs). I tend to let it run for a while and open more than one file, so it doesn't get that high on the list. I also cd and ls a lot.

A Lithiuanian light lager, 0.33 bottle. Colour is light straw while the foam is pure white. As most lagers, this is filtered and not bottle-conditioned. The foam leaves some signs behind, but not much. Smell is not very particular in any direction; a bit fresh and maybe a hint of summer, but not very strong.

The beer tastes a bit like an ale with the rounder, more friendly taste than the fizzy and almost angry lagers. Decent amounts of carbonation, but absolutely not too much. Medium bitterness with a tiny, tiny hint of citrus.

All in all, an interesting enough light beer, but those aren't among my favourites, so it falls through because of that.

I am currently working on something which hopefully end up being a good calendar server. The goal is to make it easy to add new frontends such as a CalDAV frontend, a Web frontend, etc.

So far, I am just working on getting the data model right. The iCalendar RFC has a data model which I am trying to formulate into SQL, something which is ending up being quite hard. Shannon Clark blogs about why calendars are hard, and all of those issues are issues I am running up against when trying to make the data model.

The main problem seems to be related to time zones, more closely: "How do you store timezone information in your database". The easy (but wrong) solution is to just normalise everything to UTC. This will not handle the case of events crossing timezone changes, such as to or from daylight savings.

What I am currently considering is making sure all data in the database is stored in UTC, but also store the original time zone information. While a bit more complex, this allows applications to get back the same timezone they put in (I am not convinced Evolution will be happy if the timezones are renamed, for instance) and it allows my application to generate recurring events properly. My main issue with this is having the application responsible for making sure the data in the database makes sense, but without putting half my app in PL/perl, I can not see a way around that.

Oh, and if anybody has great ideas on how to represent timezones in a relational database (postgres), please do mail me or grab me on IRC or something similar.

If you are using "loose" when you mean the opposite of win, please stop. Use "lose". Loose is the opposite of tight.

Similarly, "noone" is (almost always) wrong. You mean "no one". Noone is an obsolete form of "noon" (mid-day).