Subject: Re: [boost] [gsoc 2013] chrono::date
From: Anurag Kalia (anurag.kalia_at_[hidden])
Date: 2013-04-25 18:06:30
> If we were to say:
> typedef std::chrono::duration
> std::int32_t, std::ratio_multiply<std::chrono::hours::period, std::ratio<24>>
> > days;
> typedef std::chrono::time_point
> std::chrono::system_clock, days
> > day_point;
> We would have a time_point and duration with a precision suitable for counting sunrises. We could also easily create a clock that ticked once per sunrise.
> Now when you get 1000 ticks of this clock, you can know that 1000 days have passed. And yes, 1000 days can be converted to seconds. And when doing so you'll get 86,400,000 seconds. And if it matters that the correct answer is 86,400,001 seconds because you've crossed a leap second boundary, then you need specialized tools for that level of precision. People who need such precision rightly don't trust general purpose tools.
> To put this into perspective, the std::chrono::system_clock on your computer (if it is implemented on your platform) is counting seconds since New Years 1970 UTC, with a precision of seconds, or perhaps milliseconds, or maybe even microseconds (on my system it is microseconds). As I write this, my computer claims it is 1,366,849,370,271,425 microseconds past New Years 1970 UTC. And absolutely no one sends in bug reports that this number is 25,000,000 microseconds too low (http://en.wikipedia.org/wiki/Leap_seconds). No one cares or expects the precision to be better than 0.00000001829024.
> The very few people who do care, refuse to use UTC. They use TAI (http://en.wikipedia.org/wiki/International_Atomic_Time) instead, which does not include leap seconds. And needless to say, they aren't using the POSIX getimeofday() on their laptop to get the current time (which is what std::chrono::system_clock is commonly based on). They've got atomic clocks ticking 9,192,631,770 times a second.
Thanks a lot. I am sorry to say that I am one of the pedants who mourn the loss of a leap second. But I realise that over a course of 5000 years, UTC and TAI would diverge by approximately an hour, which is not enough to change dates in both time standards. Moreover, over such large intervals (as you so helpfully pointed out) an error margin of 1 day really does not matter. Suddenly, chrono because a very palatable foundation for the library.
> To verify my claims about your std::chrono::system_clock, I encourage you to play with the following code. If you discover I'm wrong, I would really appreciate being corrected. I do not have in my possession all implementations of <chrono>, nor access to all platforms. So I depend upon people such as yourself to tell me what you're seeing.
> #include <chrono>
> #include <ctime>
> #include <iostream>
> using namespace std;
> using namespace std::chrono;
> typedef duration<int, ratio_multiply<hours::period, ratio<24> >::type> days;
> system_clock::time_point now = system_clock::now();
> system_clock::duration tp = now.time_since_epoch();
> days d = duration_cast<days>(tp);
> tp -= d;
> hours h = duration_cast<hours>(tp);
> tp -= h;
> minutes m = duration_cast<minutes>(tp);
> tp -= m;
> seconds s = duration_cast<seconds>(tp);
> tp -= s;
> std::cout << d.count() << "d " << h.count() << ':'
> << m.count() << ':' << s.count();
> std::cout << " " << tp.count() << "["
> << system_clock::duration::period::num << '/'
> << system_clock::duration::period::den << "]\n";
> time_t tt = system_clock::to_time_t(now);
> tm utc_tm = *gmtime(&tt);
> std::cout << utc_tm.tm_year + 1900 << '-';
> std::cout << utc_tm.tm_mon + 1 << '-';
> std::cout << utc_tm.tm_mday << ' ';
> std::cout << utc_tm.tm_hour << ':';
> std::cout << utc_tm.tm_min << ':';
> std::cout << utc_tm.tm_sec << '\n';
This example also proved invaluable. After tweaking it, I have a good idea now of how to use Julian Dates (+/- reasonable constant) to represent dates. Thank you!
PS: Since this ML is heavy traffic, is it okay for me to send such thank you emails? I really wanted to, but I am not sure how they are received.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk