Boost logo

Boost :

From: George A. Heintzelman (georgeh_at_[hidden])
Date: 2001-03-22 09:30:00


> Speaking of implementation independent timing classes reminded me that I
> will very shortly be needing some way of representing dates and times in a
> project I am working on. Does anyone have any recomendations? This is the
> sort of library I would have thought would be ideal for boost.

I think this would be great to have standardized, even at the standard
time() granularity of one second. I've seen many tries at such classes,
none of them wholly satisfactory. A few things that I have observed
which I think should be taken into account in any such classes:

1) It should be as independent of other services (say, calendaring) as
possible. Lightweight is quite important here. However, it should be
easy to attach things like, adding one business day to a date to the
basic class without fuss and muss.
2) There is a definite need for dates without times and times without
dates. Often one wants to test dates for equality without worrying
about whether the seconds match up; often one wants to represent that,
say, the NYSE is open from 9:30 AM to 4 PM.
3) Timezone issues are a real sticky problem. Speaking off-the-cuff, I
think that what should be done is that the internal data for a
particular instant should be timezone-independent, with a
locale-dependent translation to date-only, time-only or text-based
representations. Effort will have to be spent making sure that the only
people who have to worry about timezone issues are people who, well,
have to worry about timezone issues anyway (doing business across
timezones and so forth).
4) It is absolutely essential to have many (preferably potentially
user-defined) ways of presenting and reading a text-based
representation. A lot of effort will need to be spent on stream
manipulators to achieve this. This is because virtually every
client-server system which sends date/time information uses a slightly
different representation for its 'standard form'.

If you build it, they will come. Or at least I will!

George Heintzelman
georgeh_at_[hidden]


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk