Maybe you could be a little bit more specific about how this is
'failing' -- runtime or compile time...
My apologies. I stated my problem in haste, and made a poor show of
it. Let me try harder.
1. I believe I need to do arithmetic on time lengths using the %
operator. So I need to get at some sort of integer that represents
them. I have been using the .ticks() to get my integer out and the
nanosec() class to put things back into periods. However I notice that
using namespace boost::posix_time;
using namespace boost::gregorian;
// ...
LONGLONG res = 1548000000000;
LONGLONG otherres = nanosec(res).ticks();
if (otherres != res)
TRACE("Eeek\n"); // Send to debug window
puts "Eeek" on my debug console. So nanosec() does not work as the
inverse of ticks(). (Perhaps it takes a long?) So having done
arithmetic on a value obtained from ticks(), how should I be poking it
back in?
2. Even if it worked, I hate using nanosec() for this job anyway. If I
am pulling something out with ticks(), I feel I should be putting it
back as ticks(). So that I could change to the cheap and cheerful
microsecond only resolution and have it still work.
I suspect maybe I could if I had access to a private constructor of
yours
explicit time_duration(tick_type ticks) :
date_time::time_duration(ticks)
{}
but obviously this is Not For Me. So I suspect that I am missing
something.
3. Furthermore, I have a suspicion that my technique is all wrong, and
that somewhere there is a Much Better Way which the libaray
anticipates. Let me set out my ideal, as a punter, merrily ignoring
the constraints of real life. I would like to see (say) methods of the
ptime class, floor() and ceil(), that worked like this
ptime t1(date(2002,Jan,10), time_duration(5,27,31));
// t1 is 2002/01/10 05:27:31
ptime t2(t1.floor(minutes(5));
// t2 is 2002/01/10 05:25:00
// ie previous five minute boundary
ptime t3(t1.ceil(seconds(10));
// t3 is 2002/01/10 05:27:40
// ie next 10 second boundary
I would like this to work from multiples of days down to multiples of
nanoseconds. I am prepared to specify an origin - eg 1/1/1970 - as a
second parameter which usually defaults, and I certainly do not wish
to be tripped up by the scary sounding leap seconds that you mention
in your docs.
Don't want much, do I? :-) But it's a bit similar to the algorithm
stuff you do with dates, so I thought it might be in there somewhere.
TIA for any pointers.
---
FYI the Change History document 'Changes.html' for Date/Time is
missing from both the Boost website and the archived docs, and the
typo 'tommorrow' for 'tomorrow' has snuck in as a variable name in
various example programs - see Google for details. C++ programming is
beyond me, but proof reading I can do <g>
Regards
Will Watts
