wallet/rotime.h

#pragma once
namespace ro {
	//	need to define my own time types:
	typedef time_t time_t;  //	is always time in seconds past the epoch modulo 2 ^ 64
							//	equivalent to regular old time_t
							//	except in environments where time_t is seconds past the epoch
							// modulo 2 ^ 32
	ro::time_t time();
	//	equivalent to regular old time(nullptr);
	//	except in environments where time_t is seconds past the epoch modulo 2 ^ 32
	typedef std::chrono::duration<int64_t, std::ratio<1, 1> > sec;
	typedef std::chrono::time_point<std::chrono::system_clock, ro::sec > sec_t;
	ro::sec_t system_time_now();
	//	Also equivalent to plain old time_t, except with modern C++14 type distinction
	//	between time points and time durations
	std::string iso_utc_time(ro::time_t t);
	std::string iso_utc_time(ro::sec_t t);
	//	which is a string expressing the utc time
	std::string iso_local_time(ro::time_t t);
	std::string iso_local_time(ro::sec_t t);
	//	which is a string expressing the local time

	typedef std::chrono::duration<uint32_t, std::ratio<1, 1000> > msec;

	// duration past startup time modulo 2^32 Rolls over every forty eight days, making
	//	durations longer than twenty four days of unclear sign
	msec msec_since_epoch(void);
		//	Obliterates chrono's elegant but pain in the ass distinction between time points and
		//	durations.	Which type distinction in practice gets in the way off all sorts of things
		//	that just need to be done.
		//	In truth, it is a distinction that only matters, and is indeed only meaningful, with
		//	respect to shared global consensus time, universal coordinated time.	It is not
		//	meaningful for steady time or high precision time, which means that all sorts of stuff
		//	gets assigned to the wrong type, a duration when you need it to be a time point, or a
		//	time point when you need it to be a duration.
		//
		//	A time point is just a duration relative to some globally agreed consensus time point,
		//	and if you don't have such a consensus, forget it.  And when you are measuring
		//	millisecond times, you do not have such a consensus.
		//
		//	millisecond clocks are not expected to be synchronized between systems, nor to
		//	measure milliseconds exactly nor to be exactly the same time unit between systems,
		//	but they are expected to advance similarly on both systems for the life of any
		//	connection, making the distinction between time points and durations problematic.
		//	We expect to compare the change in time on one system, with the change in time
		//	on another system, in which case the time point class gets in the way.
}