3 ms·

I once (maybe it's in different state now) looked at C++ boost package that was supposed to work with dates and times. It had immense number of classes (or meth

by acqq 10y ago

I once (maybe it's in different state now) looked at C++ boost package that was supposed to work with dates and times. It had immense number of classes (or methods or whatever) and was for my needs completely useless. The way I remember them, the most of the classes (or methods) were to provide "abstractions" but whoever designed "abstractions" designed them without having ever doing any non-trivial job with time and therefore the abstractions were in tons but nothing I could use. I had the similar impression for a lot of boost packages: an immense amount of red tape all around, but no "meat." But hey, also every imaginable C++ feature is used. Then I've discovered that Google at that time forbade developers using the whole boost and I've felt a bit better.

gpderetta 10y ago
That's honestly sounds like FUD. The Boost community has rejected OO design and abstractions from the very beginning embracing the STL design instead. Dates and times is a complex problem, you won't find a simple solution for it. For the record boost.date_time ony has concrete classes and no abstractions. It barely uses templates. "Then I've discovered that Google at that time forbade developers using the whole boost" Their loss.
- acqq 10y ago
  I haven't checked recently, at that time the classes didn't support the historical time zone calculations. I've looked at a lot of code (yes, they were not hierarchical classes, but there was a lot of code) but there were really only the most trivial things supported. And I admit, I never liked Boost, I am biased. But that doesn't mean that I'm misrepresenting how little what it had matched my needs, and the "bloat" feeling I've (and obviously Google too then) had.
  - gpderetta 10y ago
    Not sure what you mean by historical time zones. If you are referring to DST rules, boost.Date_Time released in Boost 1.34, which was released almost 10 years ago has a member function dst_local_start_time(year) for a time_zone object which returns 'The date and time daylight savings time begins in given year'. The doc links for older releases seem to be broken on boost.org, so I can't check if the functionality is even older.

by acqq 10y ago

gpderetta 10y ago

That's honestly sounds like FUD. The Boost community has rejected OO design and abstractions from the very beginning embracing the STL design instead. Dates and times is a complex problem, you won't find a simple solution for it. For the record boost.date_time ony has concrete classes and no abstractions. It barely uses templates. "Then I've discovered that Google at that time forbade developers using the whole boost" Their loss.

acqq 10y ago
I haven't checked recently, at that time the classes didn't support the historical time zone calculations. I've looked at a lot of code (yes, they were not hierarchical classes, but there was a lot of code) but there were really only the most trivial things supported. And I admit, I never liked Boost, I am biased. But that doesn't mean that I'm misrepresenting how little what it had matched my needs, and the "bloat" feeling I've (and obviously Google too then) had.
- gpderetta 10y ago
  Not sure what you mean by historical time zones. If you are referring to DST rules, boost.Date_Time released in Boost 1.34, which was released almost 10 years ago has a member function dst_local_start_time(year) for a time_zone object which returns 'The date and time daylight savings time begins in given year'. The doc links for older releases seem to be broken on boost.org, so I can't check if the functionality is even older.