Boost.Chrono

[Torsten Mueller]

I am told to port a piece of code (some ten thousend lines) from
Boost.Date_Time to Boost.Chrono.

But ... the more I read the documentations and try out myself some
things I get a lot of questions.

The code uses absolute timestamps a lot. This is what
boost:osix_time:time implements excellently.

I must realize the following things:
- parse strings and fill up the values into ptime objects
- generate readable and technical strings based upon ptime instances
- serialize ptime obects into a binary file and read again on another
machine (no common clock (!) between the machines ...)
- store ptime values in an SQL database and read again
- handle DST in some aspects
- extract the date or the time or the day of week from a timestamp

I guess this all will really get very complicated using Boost.Chrono.
Boost.Chrono is designed for other purposes, mostly for handling
durations, where the absolute point in time does not much interest, but
much more the difference between two points. This is handy for timers
and measurement especially if thread based clocks are used, but not for
holding and especially manipulating date and time values. I even can't
print out a typical timestamp representation like
"2014-04-10T12:34:56.123456" from a boost::chrono::time_point without
starting a massive calculation based on the concrete epoch of it's
clock ...

Has anyone expierences with that?
Is Boost.Chrono the right way for me?
Is there any reason not to use Boost.Date_Time in future?

T.M.

 

[Victor Bazarov]

I am told to port a piece of code (some ten thousend lines) from

You are told. By whom?

Boost.Date_Time to Boost.Chrono.
[...]
Is Boost.Chrono the right way for me?
Is there any reason not to use Boost.Date_Time in future?

Can you ask the person who told you to do that? What's the point of our
guessing (without even seeing the code) when (a) the decision has
already been made, and (b) most likely there was some kind of discussion
prior to making the decision, and the arguments made during that
discussion probably have more weight with those who make the decision
than any of our opinions?

I am not saying Boost.Chrono is the right way or vice versa. I am
saying that we are not the best source of information for you,
especially given pretty much total absence of evidence in the case.

V

 

[Torsten Mueller]

You are told. By whom?

By my senior developer? The motivation is "Boost.Chrono is more standard
in C++11". And this is the only item on the list of arguments.

Boost.Date_Time to Boost.Chrono.
[...]
Is Boost.Chrono the right way for me?
Is there any reason not to use Boost.Date_Time in future?

Can you ask the person who told you to do that?

Sure. I did. But I would also ask someone who tried this already. Seems
that there are not many people doing this change.

I am saying that we are not the best source of information for you,
especially given pretty much total absence of evidence in the case.

I don't agree with that. I asked a question that gives enough evidence
about what the code does. Someone who knows Boost.Chrono could easily
say how this could be solved (or not).

T.M.

 

[Victor Bazarov]

You are told. By whom?

By my senior developer? The motivation is "Boost.Chrono is more standard
in C++11". And this is the only item on the list of arguments.

Boost.Date_Time to Boost.Chrono.
[...]
Is Boost.Chrono the right way for me?
Is there any reason not to use Boost.Date_Time in future?

Can you ask the person who told you to do that?

Sure. I did. But I would also ask someone who tried this already. Seems
that there are not many people doing this change.

I am saying that we are not the best source of information for you,
especially given pretty much total absence of evidence in the case.

I don't agree with that. I asked a question that gives enough evidence
about what the code does. Someone who knows Boost.Chrono could easily
say how this could be solved (or not).

Let me see if I understood you.

You were told to do something by your manager (effectively). The "only"
reason you were given was that the proposed way is "more standard"
(probably meaning that you're supposed to switch from using Boost to
using C++11's <chrono> header and its mechanisms).

You have made some effort to estimate the work needed for the porting,
and you've discovered that it's not as straightforward as the manager
may think (hopefully there was some thought involved).

Two possible motivations to ask about it here instead of coming back to
your manager to discuss this. One possibility is that you doubt that
you know the correct way to implement the portions of the existing
functionality (that you listed in your original post) using <chrono> (or
Boost.Chrono, which is almost the same thing), in which case you would
like somebody who has attempted the same work in the past to give you
guidance. The other possibility is that you don't doubt that the
proposed library is wrong (given that you "guess this all will really
get very complicated using Boost.Chrono") yet you feel that your
argumentation carries little weight with your manager and you need some
reassurance from somebody who has also found the same reasoning for
*not* using Boost.Chrono for the things you must realize.

Hopefully the time you already spent on this was not wasted, because you
seem to have approached it from the right angle of attack. You have
collected and enumerated the main features describing the functionality
your code needs to have. You studied Boost.Chrono to the point of
familiarity, and you can judge what its main purpose is. From where I
stand, it's the right time and the right amount of information to
approach your "senior developer" and have another discussion about the
merits of switching to Boost.Chrono. The fact that you got no topical
response from c.l.c++ should be another argument for bringing that
discussion to the two of you.

A few years back I'd have expected much more traffic here, and that's
not necessarily the indication that C++ is getting less attention now.
The language and libraries (especially Boost) are much more mature, and
have more specialized functionality which leads to fewer people's
ability to claim expertise in some of them. OTOH there are other venues
for discussion. Did you know that Boost.org has its own forums?

The C++11's <chrono> header with its contents are quite new, and I would
venture a guess that www.boost.org probably has still *more* information
about how (or even whether) to use Boost.Chrono for the functionality
you mentioned, than c.l.c++.

Try those alternative approaches. Best of luck in whatever you decide
to do!

V

 

[Torsten Mueller]

Let me see if I understood you.

You did. Thanks for taking this seriously.

The other possibility is that you don't doubt that the proposed
library is wrong (given that you "guess this all will really get very
complicated using Boost.Chrono") yet you feel that your argumentation
carries little weight with your manager and you need some reassurance
from somebody who has also found the same reasoning for *not* using
Boost.Chrono for the things you must realize.

This is the point. (But I wouldn't steer the discussion from the
beginning by telling the audience my point of view.)

Sometimes decisions are just made based upon somehow irrational or even
unlogical arguments. Sometimes they say, something is more standard, the
next day something is more like the style guide, next month they have a
new style guide ..., and then some nice day the CEO visits developement
and wants everything completely different. And how to react then?
Sometimes you must just fight against the windmills because they became
real right in front of you.

From where I stand, it's the right time and the right amount of
information to approach your "senior developer" and have another
discussion about the merits of switching to Boost.Chrono.

Yes, sure, I will do this tomorrow. What I tried here was to exclude
that I could be wrong, that I could have ignored some important facts
about Chrono. I'm very familiar with all the Date_Time stuff for many
years, but I never used Chrono.

Did you know that Boost.org has its own forums?

Yes, I know. But I'm an old fashioned usenetter for 15 years.

T.M.

 

[woodbrian77]

I am told to port a piece of code (some ten thousend lines) from

Boost.Date_Time to Boost.Chrono.

But ... the more I read the documentations and try out myself some

things I get a lot of questions.

The code uses absolute timestamps a lot. This is what

boost:osix_time:time implements excellently.

I must realize the following things:
- parse strings and fill up the values into ptime objects
- generate readable and technical strings based upon ptime instances
- serialize ptime obects into a binary file and read again on another
machine (no common clock (!) between the machines ...)

http://www.boost.org/doc/libs/1_55_0/doc/html/date_time/serialization.html

Ebenezer Enterprises is willing to help you with
binary serialization. We're willing to donate
15 hours/week for six months to a project that uses
the C++ Middleware Writer.

Also we'll pay $500 and give a $1,000 investment in
the company to someone who helps us find someone
interested in this. We'll pay the $500 after working
for four months on the project. Ebenezer Enteprises
works to reward investments to 3 times the original
amount. So the investment would result in between
$0 and $3,000, depending on how things go for the company.

Brian
Ebenezer Enterprises - Because G-d discriminates.
First Corinthians 6:9 and 10.

http://webEbenezer.net

 

[Cholo Lennon]

You did. Thanks for taking this seriously.


This is the point. (But I wouldn't steer the discussion from the
beginning by telling the audience my point of view.)

Sometimes decisions are just made based upon somehow irrational or even
unlogical arguments. Sometimes they say, something is more standard, the
next day something is more like the style guide, next month they have a
new style guide ..., and then some nice day the CEO visits developement
and wants everything completely different. And how to react then?
Sometimes you must just fight against the windmills because they became
real right in front of you.


Yes, sure, I will do this tomorrow. What I tried here was to exclude
that I could be wrong, that I could have ignored some important facts
about Chrono. I'm very familiar with all the Date_Time stuff for many
years, but I never used Chrono.


Yes, I know. But I'm an old fashioned usenetter for 15 years.

Well, if you're an old fashioned usenetter, you could try
comp.lib.boost.user or comp.lib.boost.devel (prefix your subject with
[crono] or [date_time])

Regards

 

[Victor Bazarov]

Yes, I know. But I'm an old fashioned usenetter for 15 years.

Well, if you're an old fashioned usenetter, you could try
comp.lib.boost.user or comp.lib.boost.devel (prefix your subject with
[crono] or [date_time])

My server (eternal-september.org) does not carry those. Does Boost have
their own news server where these newsgroups reside?

V

 

[Cholo Lennon]

Did you know that Boost.org has its own forums?

Yes, I know. But I'm an old fashioned usenetter for 15 years.

Well, if you're an old fashioned usenetter, you could try
comp.lib.boost.user or comp.lib.boost.devel (prefix your subject with
[crono] or [date_time])

My server (eternal-september.org) does not carry those. Does Boost have
their own news server where these newsgroups reside?

V

You're right Victor, for common usetnet newsgroups I use
"news.aioe.org", but for Boost newsgroups I use "news.gmane.org"

Regards

 

[Cholo Lennon]

You did. Thanks for taking this seriously.


This is the point. (But I wouldn't steer the discussion from the
beginning by telling the audience my point of view.)

Sometimes decisions are just made based upon somehow irrational or even
unlogical arguments. Sometimes they say, something is more standard, the
next day something is more like the style guide, next month they have a
new style guide ..., and then some nice day the CEO visits developement
and wants everything completely different. And how to react then?
Sometimes you must just fight against the windmills because they became
real right in front of you.


Yes, sure, I will do this tomorrow. What I tried here was to exclude
that I could be wrong, that I could have ignored some important facts
about Chrono. I'm very familiar with all the Date_Time stuff for many
years, but I never used Chrono.


Yes, I know. But I'm an old fashioned usenetter for 15 years.

Well, if you're an old fashioned usenetter, you could try
comp.lib.boost.user or comp.lib.boost.devel (prefix your subject with
[crono] or [date_time])

Correction (thanks to Victor): The newsgroups are
gmane.comp.lib.boost.user or gmane.comp.lib.boost.devel (server:
news.gmane.org)

Regards

 

[Torsten Mueller]

Yes, I know. But I'm an old fashioned usenetter for 15 years.

Well, if you're an old fashioned usenetter, you could try
comp.lib.boost.user or comp.lib.boost.devel (prefix your subject with
[crono] or [date_time])

Correction (thanks to Victor): The newsgroups are
gmane.comp.lib.boost.user or gmane.comp.lib.boost.devel (server:
news.gmane.org)

Yeah, thanks. May be I'm old fashioned. And you too. But I still do not
see any drawbacks in doing usenet posts. It's still perfect for
discussion on technical topics and much better than web forums.

I saw the "Boost discussion groups" on the Boost website, this is
nothing else than mailing lists - today you have to explain younger
people the term "mailing lists" ... Mailing lists have already been
out-dated when Boost was born and I really thought they replaced this
years ago but they didn't.

T.M.

 

[Tobias Müller]

Yes, I know. But I'm an old fashioned usenetter for 15 years.

Well, if you're an old fashioned usenetter, you could try
comp.lib.boost.user or comp.lib.boost.devel (prefix your subject with
[crono] or [date_time])

Correction (thanks to Victor): The newsgroups are
gmane.comp.lib.boost.user or gmane.comp.lib.boost.devel (server:
news.gmane.org)

Yeah, thanks. May be I'm old fashioned. And you too. But I still do not
see any drawbacks in doing usenet posts. It's still perfect for
discussion on technical topics and much better than web forums.

I saw the "Boost discussion groups" on the Boost website, this is
nothing else than mailing lists - today you have to explain younger
people the term "mailing lists" ... Mailing lists have already been
out-dated when Boost was born and I really thought they replaced this
years ago but they didn't.

T.M.

Gmane is just a mailing list <-> NNTP gateway. Those groups are the same as
the boost discussion groups.

Tobi

 

[Jorgen Grahn]

Yes, I know. But I'm an old fashioned usenetter for 15 years.

Well, if you're an old fashioned usenetter, you could try
comp.lib.boost.user or comp.lib.boost.devel (prefix your subject with
[crono] or [date_time])

Correction (thanks to Victor): The newsgroups are
gmane.comp.lib.boost.user or gmane.comp.lib.boost.devel (server:
news.gmane.org)

Yeah, thanks. May be I'm old fashioned. And you too. But I still do not
see any drawbacks in doing usenet posts. It's still perfect for
discussion on technical topics and much better than web forums.

I saw the "Boost discussion groups" on the Boost website, this is
nothing else than mailing lists - today you have to explain younger
people the term "mailing lists" ... Mailing lists have already been
out-dated when Boost was born and I really thought they replaced this
years ago but they didn't.

T.M.

Gmane is just a mailing list <-> NNTP gateway. Those groups are the same as
the boost discussion groups.

Two observations from someone who has never used Gmane:

- It really /is/ bidirectional, like your <-> indicates. For mailing
lists where non-subscribers can post, anyway.

- http://gmane.org/about.php contains a good discussion of the
pros and cons of Usenet and mailing lists.

/Jorgen

 

[Tobias Müller]

Two observations from someone who has never used Gmane:

I do use it and find it very useful.

- It really /is/ bidirectional, like your <-> indicates. For mailing
lists where non-subscribers can post, anyway.

It even works for lists, where you have to subscribe.

Tobi

 

[Torsten Mueller]

Two observations from someone who has never used Gmane:

- It really /is/ bidirectional, like your <-> indicates. For mailing
lists where non-subscribers can post, anyway.

Yes, I saw this yesterday. Could indeed be a place to discuss boost
specific things. Thanks for this, never heard of this.

T.M.

 

[Stuart]

You did. Thanks for taking this seriously.

This is the point. (But I wouldn't steer the discussion from the
beginning by telling the audience my point of view.)

Sometimes decisions are just made based upon somehow irrational or even
unlogical arguments. Sometimes they say, something is more standard, the
next day something is more like the style guide, next month they have a
new style guide ..., and then some nice day the CEO visits developement
and wants everything completely different. And how to react then?
Sometimes you must just fight against the windmills because they became
real right in front of you.

Yes, sure, I will do this tomorrow. What I tried here was to exclude
that I could be wrong, that I could have ignored some important facts
about Chrono. I'm very familiar with all the Date_Time stuff for many
years, but I never used Chrono.

I don't want to appear nosy, but could keep us updated about whether you
succeeded with your appeal (ich meine "Beschwerde", weiss nicht, ob
"appeal" das genau trifft)?

During my ten years of professional programming I have been confronted
with only two occasions where the management suggested to switch the
development platform (they "heard" that DotNet is now the "standard" .

Thanks,
Stuart

 

[Torsten Mueller]

I don't want to appear nosy, but could keep us updated about whether
you succeeded with your appeal

We stopped this preliminary (another word for finally). The code remains
on Boost.Date_Time. A very good help for my point of view was the
original documentation of Chrono [1] which is mentioned in the Boost
documentation. This file contains the following paragraphs:

This paper does not offer calendrical services except for a
minimal mapping to and from C's time_t.

As this paper does not propose a date/time library, nor specify
epochs, it also does not address leap seconds. However, a date/time
library will find this to be an excellent foundation on which to
build.

(These paragraphs are lacking in the Boost documentation.)

But building an own "date/time library" now while Boost.Date_Time
already exists and is the well tested base of a lot of our code is
somehow crackbrained.

During my ten years of professional programming I have been confronted
with only two occasions where the management suggested to switch the
development platform (they "heard" that DotNet is now the "standard"
.

Wait until they hear "stored procedures are evil".

T.M.

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.htm

 

[Jorgen Grahn]

Yes, I saw this yesterday. Could indeed be a place to discuss boost
specific things. Thanks for this, never heard of this.

Thank that other guy; this was news for me too. I will consider using
it; a newsgroup is a much better way to follow something you are only
occasionally interested in.

/Jorgen