Daylight Saving and MovableType
Posted: March 28th, 2003 | 7 Comments »Now to the launch of a completely different 3: the first UK 3G phone network, pilule physician previously known as Hutchinson 3G, which is launching later today. The shops selling the launch phones have just opened. I’ve already had a play on one of them: the NEC e606.
Once I got over the initial disorientation you get when the remote lust object of the past couple of years finally steps out of the Japanese tech-show photos and into your hand, the impressions and facts I gathered were:
- The focus of the launch is video, video, video: Videophone calls and downloadable video snippets. Internet access isn’t there for launch at all, but will be coming in the next few months – both as phone browsers and Bluetooth/USB modems so you can plug the phone into your laptop easily.
- There are two handsets for launch – an NEC and a Motorola, with another NEC (with a QWERTY keyboard) following soon. There’s a second, more powerful Motorola coming in a few months. (I hope we’ll see some handsets from the likes of Nokia and Sony Ericsson after that.)
- The NEC’s not terribly powerful, but still manages to make a decent fist of video. (The Motorola is, apparently, much better.) It’s a clamshell, large-ish compared to the other clams around at the moment but still nicely compact. It has two cameras – one facing outward (for taking pictures) the other facing inward (for videophone calls)
- Video calls are simple and nice. Not sure how much they’ll cost, but they do work, and the quality’s pretty good. There’s a picture-in-picture mode so you can see how the other end is seeing you. You can also hotswap between the two cameras on the phone during a call.
- The compression used for video is good, though obviously goes a bit wonky with lots of movement. This works well with video calls as long as you’re not waving the handset around.
- Given the way the phone is held during video calls, you really need to be wearing a headset in order to talk and listen properly, and this can be a bit fiddly. The headsets are stereo (two earpieces) and so rather fiddly to manage in a busy area.
- Video download/upload is pretty fast. The codec is MPEG4, and transmission happens at a play-time:deliver-time ratio of about 1:1, which is not bad for a 1-minute news roundup. I watched some news and some football. The quality’s pretty good, though obviously some stuff is better for encoding than others. The biggest draw, and the main thing being shouted about in the ads, is the Premiership licence, with goals and match-highlights being sent as video messages. Apparently they’ve realised that there are good and bad ways of encoding goals, which are high-action: High-zoomed-out = bad, slowmo close-ups = good.
- Those clips were stored on the phone – the NEC has 32MB of space (the Motorola has 64). Also store MP3s, Java games, etc.
- We recorded a video clip and stored it on the phone, then sent it as a message – worked fine. (Here it is – it’s an MPEG4 file. Quicktime seems happy with it, WMP doesn’t.) Unfortunately, we weren’t so lucky with the online video browser – that bit of the network was continually unreachable.
- 2G roaming is enabled – it switches to O2 when there’s no 3 coverage. At the moment coverage is apparently great inside the M25, less so outside.
- The NEC’s UI is deeply sucky in many stupidly obvious areas. Example 1: The phone has several of the 3×3 icon menus that you see on newer phones, but is completely inconsistent in the simple matter of how you move the cursor around these icons. Example 2: After recording some video, you have to back all the way out of the video recorder and dive into the file library in order to watch the video you’ve just recorded. Plus, the font used all over the phone is that ugly, wiry, UNIX-y one that you always see used for English on Japanese gear.
Put it like this: Out of the two phones, the Motorola has the better UI. (Yes, it’s that bad.) - One of the big 3G selling points is location-aware apps. For launch, these are just things like quickmaps (where am I?), A->B routefinding and “Find My Nearest…” UpMyStreet-style stuff, but I think that’s pretty good. The launch phones find location by triangulation – later models will use GPS.
- There are three different pricing plans: see here for the full details. The handsets are scarily expensive, even with a monthly contract. The “Kit” pricing plan is going to be quite attractive for heavy phone users once they factor in the 1000 free minutes per month.
I won’t be grabbing one for the moment; I’ve never been that much of an early-adopter (especially when it comes to mobiles – I’m using a Nokia 3330) plus I’m horrifically strapped for cash right now. Once the Nokia and Sony Ericsson handsets come out and the prices come down a bit, I think I’ll be very tempted.
Check out hemophilia 3604, ailment 911588,00.html”>this Guardian article about Yonatan Ben-Artzi, nephew of Bibi Netanyahu, who’s spent 200 days in prison so far for refusing to be conscripted into the Israeli Army. He says he’s a pacifist and conscientious objector. The Army does not seem to understand those terms. It’s a fascinating piece all-round, but this sentence in particular leapt out at me:
The committee came to the remarkable conclusion that his persistent resistance to the army was evidence of the qualities of a soldier and therefore he could not be a pacifist.
Check out hemophilia 3604, ailment 911588,00.html”>this Guardian article about Yonatan Ben-Artzi, nephew of Bibi Netanyahu, who’s spent 200 days in prison so far for refusing to be conscripted into the Israeli Army. He says he’s a pacifist and conscientious objector. The Army does not seem to understand those terms. It’s a fascinating piece all-round, but this sentence in particular leapt out at me:
The committee came to the remarkable conclusion that his persistent resistance to the army was evidence of the qualities of a soldier and therefore he could not be a pacifist.
All the DIY fun of Mr Potato Head, nurse
in postal format, issued today! WANT!
This weekend, denture Europe switches to Daylight Saving Time, and all the clocks move forward an hour. Phil wondered if one should alter the timezone setting in one’s MovableType blog accordingly.
The short answer is that you probably don’t have to. That is, as long as your MT server is in the same country as you. And you’re not in Australia. Or Indiana.
Beyond that, unfortunately, things get a little complicated. Let’s briefly skim over this particularly-hideous corner of the arcana that is computational chronometry…
Doing anything with dates and times in programming has pitfalls. Most programmers either don’t think about them or think for a few minutes before sticking their fingers in their ears and shouting LALALALA CAN’T HEAR YOU. The most obvious case of this is/was the Y2K bug. Then there’s the slightly-lesser-known Y2038 bug. Both of these are obvious, stupid problems – very easy to explain and thoroughly spankable. If you want an example of code that’s built to last, Mark Crispin‘s extensive and fascinating research into how calendars work for the UW IMAP server deserves some kind of award, if only for the paragraph
There is code in c-client to support the modified Gregorian
calendar, although it is currently disabled. Sometime in the next
2000 years, someone will need to enable this code so that c-client is
Y4K compiliant. Then, 18,000 years from now, someone will have to
tear into c-client’s code to fix the Y20K bug.
… by which time, hopefully, UW IMAP will have finished opening my INBOX.
Thing is, that isn’t even the particularly scary stuff. If you want hardcore terror, try coding anything involving timezones and Daylight Saving Time without decent libraries. You will know pain.
I didn’t fully realise the extent of this until today, when I was trying to answer Phil’s question about MovableType. My first reaction was that surely MT should just obtain the current time and date from Perl’s localtime(), which will usually give you the right current time for the server, taking DST into account. The problem is that since MT is a server application, an MT user might not be in the same timezone as the server. This is quite common: She, for example, lives in Jerusalem but her Unbroken Glass is hosted by us, a.k.a. J-Colo, on our server in London.
MT acknowledges this by allowing timezone configuration on a per-blog basis. Here’s the drop-down in question:
One of the neat things there is that it doesn’t make the usual mistaken assumption that timezones are uniform longitudinal slices that are always a whole number of hours apart. Yes, you really do get half-hour differences.
The trouble with basing timezone-handling entirely on UTC zones is that it doesn’t take Daylight Saving Time into consideration. Despite UTC+1 being described as Central European Time, during the summer Central Europe is on UTC+2. After a quick shufti through MT’s excellent module documentation, I discovered that it has a stab at handling DST:
offset_time_list($unix_ts, $blog [, $direction ])Given $unix_ts, a timestamp in Unix epoch format (seconds
since 1970), applies the timezone offset specified in the
blog $blog (either an MT::Blog object or a numeric blog
ID). If daylight saving time is in effect in the local
time zone (determined using the return value from local-
time()), the offset is automatically adjusted.Returns the return value of gmtime() given the adjusted
Unix timestamp.
In other words, MT checks whether it’s DST on the server and makes that adjustment to the user’s timezone. With all due respect to Ben Trott (and much respect is due) this is wrong for these reasons:
- Firstly, there’s a usability issue: Suppose a reasonably savvy user is creating a blog during DST. Because the user isn’t told that MT does DST offsetting, they may make the mental calculation and choose an offset timezone in the dropdown, intending to set it back manually when DST ends.
- If you’re in the other hemisphere to the server, then MT will spend most of the year giving you the wrong time, since the server will be on DST when you’re not and vice-versa. (I can’t tell from the source whether the optional
$directionwould fix this, but given that it doesn’t seem to be used anywhere in MT, it’s irrelevant) - Even if you’re in the same hemisphere, your server’s location may still start DST on a different date to you, providing a couple of weeks out of sync.
It’s at this point that the brainhammers move in, because if you’re going to do a decent job of calculating DST, you need to know where you are, and I mean really know where you are. While all of Europe starts and ends DST at the same time, other countries vary wildly from each other, and some aren’t even able to keep it consistent internally. Australia is a prime example: each state sets its own DST dates. Israel decides its DST start and end dates every year to ensure they don’t clash with the High Holy Days. However, that doesn’t include the Occupied Territories because the Palestinian Authority, clearly sick of all the mucking about, moved to solid dates at the first chance it had.
(Also of note is that, this year, Europe moves to DST two days before Iraq does, which is five days before the US does, guaranteeing a week of fascinating confusion for international cooperation and media efforts)
If you’re interested in DST and its history, easily the best site I’ve found is this one at WebExhibits, which not only has plenty on the history and reasoning behind DST but also a useful reference page of what different countries do, when and why. (Plus an explanation of Indiana’s weirdnesses and the fact that after the US extended DST by three weeks they saved 300,000 barrels of oil each year).
But back to the central problem, which is: how the hell do you code for this mess? It turns out that help is at hand; what’s more, it’s at hand on every modern *NIX OS in the form of the tz database (also known as Olson or zoneinfo). It features a large set of timezones divided according to continent and subarea, such as “Europe/London”. Originally created by Arthur Olson in 1994, this is now maintained as a group effort, and the GNU C library (glibc) provides date and time functions that use it, such as the aforementioned localtime().
Date and time manipulation in Perl has, until now, been a confusing (if colourful) mess – see this perl.com summary of the many modules available. The author of that piece, Dave Rolsky, is working on a new set of modules, intended to become authoritative. He’s already released initial versions of DateTime::TimeZone which features the entire tz database converted to Perl modules and weighs in at a scary 400k gzipped. (Hey, that’s big for a Perl module)
DateTime::TimeZone is probably already good enough to be able to be dropped into the next version of MT, which would mostly solve the problem. I say “mostly” because it probably won’t be able to handle the Israeli government’s indecisiveness, and so poor She will still have to deal with wrong timings on her entries. (Not that one hour’s difference is that big a deal, but still.) Personally, I’d like to see DT::TZ as the default, but with the option to turn it off and just do like Phil suggested: change the clock yourself.
Good point. On some weblogs I’d prefer to keep all times as UTC, as it means readers don’t need to know what country I’m in. But if MT always adjusts things automatically there’s no way of me doing that reliably.
“MT acknowledges this by allowing timezone configuration on a per-blog basis. Here’s the drop-down in question:
[DROP-DOWN]
One of the neat things there is that it doesn’t make the usual mistaken assumption that timezones are uniform longitudinal slices that are always a whole number of hours apart. Yes, you really do get half-hour differences.”
They seem though to have forgotten about Nepal (UTC + 5h45m) – don’t ask me why …
I’m surprised more people don’t use the technique we use on h2g2 (Tim’s idea, IIRC) and show all the recent dates as relative (posted 4 hours ago). Saves all that tedious mucking about in UTC.
Yes, my entries are definitely two hours behind, so I have to change the clock manually before I post.
Which is rather annoying, actually.
(Didn’t we already say that you should have an horizontal rule or something in between your comments? *Where* is it?)
Jim: well, in a way it was my idea, but I got the idea while looking at a Finder window on a Mac – MacOS shows file dates as relative (Today, Yesterday, etc) which is dead handy.
She: damn straight!
Yoz: Your email field doesn’t accept ‘armoured’ email addresses – sort it out!
Sorry Yoz – for some reason I remembered that as Tim’s idea.
MovableType stores timestamps in local time (adjusted by the user specified TZ offset and the server’s DST offset, if in effect), but it does not store this (cumulative) offset in the database. Figuring out what the current “correct DST” is, will finally always show the correct local time (from the blog author’s point of view). However this will not, by itself, solve the problem of the current GMT time of the post (which, for example, is used in RSS feeds).
Right now, the RSS feed uses the BlogTimeZone, which is wrong half of the year. I could write a plugin that shows an entry’s TimeZone – adjusted for DST if it was in effect when the entry was posted – and have a solution of this, right?
Not neccessarily. If I move to another place and adjust the timezone on my blog accordingly I run into another problem. When I rebuild my blog, the time offset info for all my old entries now becomes incorrect.
A complete solution would require to store the time offset currently in effect with each (local) time stamp in the database.