Forum libero

ah ok.
e questa frase?

Likewise, let's ignore leap seconds. This isn't always a good idea, and there are some wrinkles around library support. For example, Java explicitly says that java.util.Date and Calendar may or may not account for leap seconds depending on the host support. So, it's good to know how predictable that makes our software... I've tried reading various explanations of leap seconds, and always ended up with a headache. For the purposes of this talk, I'm going to assert that they don't exist.


Okay, so let's start with something simple. Tony, what's the time on this slide? (Tony whispers) Tony doesn't want to answer. Anyone? (Audience responds.) Yes, about 5 past 3 on October 28th. So what's the difference between now and the time on this slide? (Audience response.) No, it's actually nearly twelve hours... this clock is showing 5 past 3 in the morning. Tony's answer was actually the right one, in many ways... this slide has a hopeless amount of ambiguity. It's not as bad as it might be, admittedly. Imagine if it said October 11th... Jeff and Joel would be nearly a month out of sync with the rest of us. And then even if we get the date and the time right, it's still ambiguous... because of time zones.


Ah, time zones. My favourite source of WTFs. I could rant for hours about them – but I'll try not to. I'd just like to point out a few of the idiosyncrasies I've encountered. Let's start off with the time zones on this slide. Notice anything strange? (Audience or whisper from Tony) Yes, CST is there three times. Once for Central Standard Time in the US – which is UTC-6. It's also Central Standard Time in Australia – where it's UTC+9.30. It's also Central Summer Time in Australia, where it's UTC+10.30. I think it takes a special kind of incompetence to use the same acronym in the same place for different offsets.

Then let's consider time zones changing. One of the problems I face is having to encode or decode a time zone representation from a single pattern – something like "It's UTC-3 or -2, and daylight savings are applied from the third Sunday in March to the first Sunday in November". That's all very well until the system changes. Some countries give plenty of warning of this... but on October 7th this year, Argentina announced that it wasn't going to use daylight saving time any more... 11 days before its next transition. The reason? Their dams are 90% full. I only heard about this due to one of my unit tests failing. For various complicated reasons, a unit test which expected to recognise the time zone for Godthab actually thought it was Buenos Aires. So due to rainfall thousands of miles away, my unit test had moved Greenland into Argentina. Fail.

If you want more time zone incidents, talk to me afterwards. It's a whole world of pain. I suggest we move away from time zones entirely. In fact, I suggest we adopt a much simpler system of time. I'm proud to present my proposal for coffee time. This is a system which determines the current time based on the answer to the question: "Is it time for coffee?" This is what the clock looks like:


This clock is correct all over the world, is very cheap to produce, and is guaranteed to be accurate forever. Batteries not required.

So where are we?


The real world has failed us. It has concentrated on local simplicity, leading to global complexity. It's easy to organise a meeting if everyone is in the same time zone – but once you get different continents involved, invariably people get confused. It's easy to get writing to work uniformly left to right or uniformly right to left – but if you've got a mixture, it becomes really hard to keep track of. The diversity which makes humanity such an interesting species is the curse of computing.


When computer systems have tried to model this complexity, they've failed horribly. Exhibit A: java.util.Calendar, with its incomprehensible set of precedence rules. Exhibit B: .NET's date and time API, which until relatively recently didn't let you represent any time zone other than UTC or the one local to the system.


Developers have, collectively, failed to understand both the models and the real world. We only need one exhibit this time: the questions on Stack Overflow. Developers asking questions around double, or Unicode, or dates and times aren't stupid. They've just been concentrating on other topics. They've made an assumption that the core building blocks of their trade would be simple, and it turns out they're not.


This has all been pretty negative, for which I apologise. I'm not going to claim to have a complete solution to all of this – but I do want to give a small ray of hope. All this complexity can be managed to some extent, if you do three things.

First, try not to take on more complexity than you need. If you can absolutely guarantee that you won't need to translate your app, it'll make your life a lot easier. If you don't need to deal with different time zones, you can rejoice. Of course, if you write a lot of code under a set of assumptions which then changes, you're in trouble... but quite often you can take the "You ain't gonna need it" approach.

Next, learn just enough about the problem space so that you know more than your application's requirements. You don't need to know everything about Unicode – but you need to be aware of which corner cases might affect your application. You don't need to know everything about how denormal number representation, but you may well need to know how rounding should be applied in your reports. If your knowledge is just a bit bigger than the code you need to write, you should be able to be reasonably comfortable.

Pick the right platforms and libraries. Yes, there are some crummy frameworks around. There are also some good ones. What's the canonical answer to almost any question about java.util.Calendar? Use Joda Time instead. There are similar libraries like ICU – written by genuine experts in these thorny areas. The difference a good library can make is absolutely enormous.

None of this will make you a good developer. Tony's still likely to mis-spell his “main” method through force of habit. You're still going to get off by one errors. You're still going to forget to close database connections. But if you can at least get a handle on some of the complexity of software engineering, it's a start.

Thanks for listening.