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.
Congrats on a major milestone for Project X! All the best of Project M too. It sounds intriguing. 🙂
I noticed that some operating systems use an environmental variable TZ, which is set to something like EST05EDT or America/New_York. Of course, that’s probably a very unreliable way to handle things, considering how many novices use operating systems now. There should also be a symlink file in Unix that tells you what time zone you’re in, known as the Zoneinfo file. That’s probably the most portable Unix way to handle it, though I haven’t checked to see if OS X copies that, and if so, does it reliably. (A lot of the stuff in /etc and other such directories isn’t checked or actually used by the OS. Its just there so people can call it Unix(tm). 😉 )
c-square: Thanks! Yes, it should be quite interesting to the small subset of people that care about that sort of thing. And that subset should be big enough to keep me in pizza and Mountain Dew for a long time. 😉
Ploni: Yes, TZ was in widespread use twenty years ago, on *NIX and even DOS machines. But today’s Linux machines rarely use it. The code I wrote checks for it first, and uses it if it’s set, but that will usually fail these days.
Yeah, I mentioned that TZ can’t be relied upon. The Zoneinfo file, however, probably can be in many cases.
Does Project M require they have internet connectivity? If so, you could do it by IP Address. It’s definitely not ironclad, but it would be OS independent.
Ploni: Um, unless I’m missing something, the zoneinfo file doesn’t exist on stock Ubuntu installations (just to name a popular one). There’s plenty of zone information in binary format, but that doesn’t give the info I need, like the underlying rules for Daylight Savings Time transitions, it only gives the actual dates of them.
c-square: It requires Internet connectivity at least part of the time for normal operations, but getting the physical location by IP address is pretty nasty, and inaccurate to boot. I’d be more inclined to just ask the user, if there were no way to get even partial information from the OS.
Well, as far as the “underlying rules” go, those have changed three times in the last two decades, and that is just in the US’s legislative tweaking alone, we’re not counting the different rules in the UK Summertime and the EU daylight savings time schemes.
Good luck with that, lots of software has had significant bugs due to DST rule changes in various countries – it’s best not to rely on this info being correct too much.
As for the ZoneInfo file, you’re probably just looking for it wrong. It’s named according to the timezone, it’s not ordinarily called “zoneinfo”. According to this, it’s in all BSD, and nearly all Linux distros due to the GNU C library’s use of it:
http://en.wikipedia.org/wiki/Tz_database
Oh yes, it’s in OS X also. Only OS it’s not in is Windows, unless it’s running CygWin.
I’m not looking for it wrong. It doesn’t exist in a stock Ubuntu installation, or most other distributions. Only the compiled binary versions exist, and they don’t have the information I need.
And yes, I’m aware that DST rules fluctuate nearly as often as hemlines, and I found that Wikipedia article as part of my initial research. My code does try to use the zoneinfo file if the TZ variable fails, and I plan to distribute a version of it with each of my non-Windows programs (Windows provides the information I need). But unlike the TZ variable, the zoneinfo file does not solve the problem I described in the entry, which is how to find out from the OS what time-zone the system is in.
(And yes, I know how to find it in Ubuntu already.)