util: Don't throw in GetTime{Millis,Micros}(). Mark as noexcept.

[practicalswift]

• boost::posix_time::ptime(boost::gregorian::date(1970,1,1) throws bad_year, bad_day_of_month, or bad_day_month (derivatives of std::out_of_range) if the year, month or day are out of range. It is obvious to us that it won't throw at run-time for 1970-01-01, but that is not obvious for the compiler or static analyzers. From a static analyzer perspective it will look like these exceptions can reach all the way up to NodeImpl::appInitMain() where they are unhandled.
• boost::posix_time::from_time_t(0) is simpler and doesn't throw.
• Re-use the result of boost::posix_time::from_time_t(0) like we're doing in DecodeDumpTime(…).
• Mark GetTimeMillis() and GetTimeMicros() as noexcept.

[qmma70]

Why not use std::chrono::high_resolution_clock?

[practicalswift]

@qmma70 I'm all for removing Boost, but that is something for another PR :-)

[sipa]

utACK bcdf285db285932365fe6cae17ba5a585cd1a17e

[DrahtBot]

The last travis run for this pull request was 55 days ago and is thus outdated. To trigger a fresh travis build, this pull request should be closed and re-opened.

[Empact]

noexcept doesn't sit right with me here.
https://google.github.io/styleguide/cppguide.html#noexcept
https://akrzemi1.wordpress.com/2014/04/24/noexcept-what-for/

[sipa]

@Empact What in particular is an argument against noexcept here?

[Empact]

I guess I'm more wondering: what is the justification for it? If it doesn't help with significant performance optimizations (ala move) and we don't expect it to affect the error performance of the method (because we don't expect it to throw) then why should we apply the treatment? If we should apply it here, should we apply it to most methods? Just a notion.

[practicalswift]

@Empact Scott Meyers has this to say about noexcept: http://aristeia.com/EC++11-14/noexcept%202014-03-31.pdf – "Declare noexcept whenever possible" :-)

[DrahtBot]

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

No conflicts as of last run.

[ken2812221]

utACK afc97c7

[maflcko]

Looks like this is made obsolete by something like #9566?

[practicalswift]

@MarcoFalke Yes, guess so.

Perhaps I should close this PR? The interest in making GetTime{Millis,Micros}() noexcept seems to be limited: only @sipa, @ken2812221 and I have expressed interest in getting this in :-)