First, for those of you who know and care about it: after seven years of work, the theory for Project X is successfully finished! (Hurray!) However, I haven’t found a simple — but not too simple — use for it so I could prove that it works. I’m not sure I’ll be able to commercialize it any time soon. On the plus side, I’ve thought of several small non-desktop-computer applications where it would be critical; on the minus side, the devices that it would go into (especially with the kind of computing power necessary for this) aren’t yet out of the labs, and likely won’t be in the next five years.
So I’ve started development on a new series of programs. The first is a “better mousetrap” that not only scratches a couple long-time itches of mine, but should be of interest to a lot of other people as well. I’ll refer to that as “Project M” on this blog from here on, and I won’t be giving away many details about it until it’s released.
One of the things that Project M is going to need is good date handling. It’s going to be used with lots of other programs and in lots of different countries worldwide, and it has to understand the dates and times for each country properly. Much of the heavy lifting for date/time handling is taken care of by the Boost.Date_Time library, but one thing it doesn’t do is tell you what time zone the current system is set to.
I was flabbergasted by this omission. Knowing the time zone that you’re in is an absolute requirement for converting times between different zones. But when I dug into it, I saw why: because it’s a hard problem. So the library author punts: you, the developer, have to tell the library what time zone it’s in, and then it will take care of everything else for you. Not necessarily all that difficult, but doing it in a cross-platform way required quite a bit of research, thought, and experimentation (which is why there was no blog entry yesterday, I was too busy working on it).
I can’t really fathom why Linux developers haven’t settled on a good standard for this. The OS knows what time zone the system is in, but it’s all but impossible to get it to divulge that information portably. Different distributions all have different ways of doing it, and most of them are ridiculously indirect.
What I ended up doing was writing code for the system that Ubuntu uses (hopefully shared by other distributions as well), and writing a fall-back method for everything else. The fall-back code uses standard C library calls to fake it. It’ll work fine for any country that ignores the insanity that is Daylight Savings Time (DST), and in any country that shares the politically motivated and apparently randomly-changing dates that DST begins and ends in the US, but will only somewhat work in other places that use DST. Without knowing the actual location of the system, that’s the best I can manage.
Hopefully Linux distributions will decide on a standard method of discovering the system time zone. Until then, there’s inevitably going to be a lot of pain and confusion when it comes to dates and times.