A former colleage of mine (Hi Nigel!) frequently wore the greatest geek tee-shirt I have ever seen to work. Ineptly reproduced here, it summarizes the realities of software development – when deciding what to implement technical considerations are often overruled by more prosaic influences.

Take this comment by another old colleage. It is a example of how a lot of companies fail to exploit the huge amount of well-tested code available for reuse. There are lots of reasons why a company might ban boost, in my opinion none of them are that compelling.

The main reason cited is the fear of legal retribution (before continuing, I should point out that I am not a lawyer and the following is not legal advice.)

More than one company has been stung by employees including code they do not own into a commercial product, even accidental violations can attract huge penalties with big companies being particularly at risk. This has resulted in a climate where a company will pass every decision on third-party libraries through their lawyers. Lawyers by nature are cautious, they live in a world of contracts, indemnities and assigned liabilities. The default answer is almost always going to be “no” unless there is a contract to sign and someone to blame if it goes pear-shaped.
Continue reading →

Living on a spherical planet can sometimes be a real pain in the neck. It makes what should be a simple concept, Time, inordinately complex. Timezones, daylight savings, leap years (and worse: leap seconds) all conspire to destroy any simple abstraction. So boost provides a complex one.

First up is the gregorian::date class, which specifies a day in the gregorian calendar (sorry fans of the French Revolutionary Calendar, boost::date_time is not for you). Along with normal days, gregorian::date supports positive/negative infinite dates as well as a special not_a_date_time value that make certain algorithms very easy.

A closely related type is gregorian::days, which represents duration. Durations can be freely added or taken away from dates to create new dates. Special classes for longer units also exist: gregorian::weeks, gregorian::months, and gregorian::years come in very handy. gregorian::months and gregorian::years even have special handling to ensure that dates “snap” to the end of the month during calculations.

gregorian::date_period represents a fixed period between two dates, and has the methods you would expect for determining if a date exists within a period or two periods overlap. Because the date class can represent abstract concepts like dates infinity days into the future or past, date_periods can represent segments of time without fixed ends.

Date Iterators and Generators are both very cool concepts. Iterators produce a series of dates that are all some duration (ie: 1 month) apart. Generators provide even more complex factories for producing non-uniform dates such a “the last monday in January” for a given year.

Times are just dates with an offset into the specified day. In boost::date_time this is handled by the posix_time::ptime class. Like date, ptime can represent positive and negitive infinity as well as not_a_date_time giving great flexibility. Also like gregorian::date there are time_duration, time_period, and time_iterator classes which serve the same purpose.

I haven’t even mentioned the most useful part of boost::date_time yet – a full set of streaming operators and conversions to and from standard string formats. If for some reason the standard input/output formats aren’t enough it is possible to imbue a stream with a custom date/time facet for that fancy touch of class.

Aside from strings, dates and times are probably the most common data-types that must be represented in programs dealing with human affairs. It is a pleasure to finally have a library that is up to the task.