[gsoc 2013] chrono::date

newer
[gsoc 2013] Approximate string...

older
Re: [boost] [gsoc-2013]...

Anurag Kalia

24 Apr 2013 24 Apr '13

11:05 p.m.

After going through related docs and general information, I have some questions regarding the chrono::date library. What is the origin of the name 'chrono'? I have assumed till now, it has something to do with chronology, but I am not sure.Why is date a part of 'chrono' at all? As I understand, chrono::date library is supposed to be based on the counts of sunrises. I am in favour of it because it elegantly circumvents the complications of leap seconds which are unnecessary with date-related arithmetic. But if we want it to be compatible with the rest of chrono library, complications arise:If we use a definition in line with principles of chrono (i.e. not using sunrises for a moment), a date really becomes a time-interval defined by the 00:00:00 of that date + a duration of 1 day, if we follow the rules of chrono library. But the length of a day can be changed today due to insertion/deletion of leap seconds to the conventional 24-hour day, if needed. Moreover, this change is arbitrary, since leap seconds are used to keep the time in sync with earth's rotations, which changes without a fixed pattern.The length of month and year similarly are complicated, not only by the length of days in it (see above) but also by the variable number of days. For example January has 31 days, April has 30 days and February has 28 or 29 days depending upon common year or leap year respectively. Due to the latter, length of year also varies between 365 and 366 days.In essence, there is no fixed duration of day, month or year; unlike the rest of chrono library which fundamentally is based on 'duration' class.Now if we revert to our original definition, our library basically becomes a count of sunrises since epoch. Aren't we forming an independent library from chrono then?What does one mean when one says the chrono::date library interoperates with rest of chrono library? This question is an offshoot of previous question. I am confused as to how far can both parts interoperate given the above-mentioned complications. Subtraction of dates yields us theoretically a duration of a number of days. But since actual time duration of a day is ill-defined (see above), we have to return the answer in resolution of seconds, if we use 'duration' at all. I am unable to think of more possibilities of cross-pollination between the two parts. Am I correct in my reasoning? I am genuinely stuck at this clubbing up of unrelated (to me) classes. Even more so because Boost already supplies such a vast number of header files with least number of interdependencies. A smaller self-contained date library seems (to me) more in line with its principles. Thanks,Anurag Kalia.

Show replies by date

Howard Hinnant

25 Apr 25 Apr

1 a.m.

On Apr 24, 2013, at 7:05 PM, Anurag Kalia wrote:

...

After going through related docs and general information, I have some questions regarding the chrono::date library. What is the origin of the name 'chrono'? I have assumed till now, it has something to do with chronology, but I am not sure.Why is date a part of 'chrono' at all? As I understand, chrono::date library is supposed to be based on the counts of sunrises. I am in favour of it because it elegantly circumvents the complications of leap seconds which are unnecessary with date-related arithmetic. But if we want it to be compatible with the rest of chrono library, complications arise:If we use a definition in line with principles of chrono (i.e. not using sunrises for a moment), a date really becomes a time-interval defined by the 00:00:00 of that date + a duration of 1 day, if we follow the rules of chrono library. But the length of a day can be changed today due to insertion/deletion of leap seconds to the conventional 24-hour day, if needed. Moreover, this change is arbitrary, since leap seconds are used to keep the time in sync with earth's rotations, which changes without a fixed pattern.The length of month and year similarly are complicated, not only by the length of days in it (see above) but also by the variable number of days. For example January has 31 days, April has 30 days and February has 28 or 29 days depending upon common year or leap year respectively. Due to the latter, length of year also varies between 365 and 366 days.In essence, there is no fixed duration of day, month or year; unlike the rest of chrono library which fundamentally is based on 'duration' class.Now if we revert to our original definition, our library basically becomes a count of sunrises since epoch. Aren't we forming an independent library from chrono then?What does one mean when one says the chrono::date library interoperates with rest of chrono library? This question is an offshoot of previous question. I am confused as to how far can both parts interoperate given the above-mentioned complications. Subtraction of dates yields us theoretically a duration of a number of days. But since actual time duration of a day is ill-defined (see above), we have to return the answer in resolution of seconds, if we use 'duration' at all. I am unable to think of more possibilities of cross-pollination between the two parts. Am I correct in my reasoning? I am genuinely stuck at this clubbing up of unrelated (to me) classes. Even more so because Boost already supplies such a vast number of header files with least number of interdependencies. A smaller self-contained date library seems (to me) more in line with its principles. Thanks,Anurag Kalia.

From: http://en.wikipedia.org/wiki/False_precision

...

A tour guide at a museum says a dinosaur skeleton is 100,000,005 years old, because an expert told him that it was 100 million years old when he started working there 5 years ago.

If we were to say: typedef std::chrono::duration < std::int32_t, std::ratio_multiply>

...

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. 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> int main() { using namespace std; using namespace std::chrono; typedef duration >::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'; } Howard

Anurag Kalia

10:06 p.m.

...

If we were to say:

typedef std::chrono::duration < std::int32_t, std::ratio_multiply>

...
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>

int main() { using namespace std; using namespace std::chrono; typedef duration >::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.

Howard Hinnant

26 Apr 26 Apr

1:38 a.m.

On Apr 25, 2013, at 6:06 PM, Anurag Kalia wrote:

...

...
If we were to say:

typedef std::chrono::duration < std::int32_t, std::ratio_multiply>

...
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>

int main() { using namespace std; using namespace std::chrono; typedef duration >::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.

Thank you, this was valuable feedback for me. Howard

Howard Hinnant

3:18 a.m.

On Apr 25, 2013, at 6:06 PM, Anurag Kalia wrote:

...

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!

In addition to: typedef std::chrono::duration < std::int32_t, std::ratio_multiply>

...

days;

which is a non-SI unit accepted for use with SI: http://en.wikipedia.org/wiki/SI_units#Non-SI_units_accepted_for_use_with_SI One can then, taking the current definition of the civil (gregorian) calendar, create several more units which can be quite useful: There are exactly 7 days in a week: typedef std::chrono::duration < std::int32_t, std::ratio_multiply>

...

weeks;

There are exactly 146097 days in 400 years, which could rightly be called an era: typedef std::chrono::duration < std::int32_t, std::ratio_multiply>

...

eras;

There are exactly 400 years in an era: typedef std::chrono::duration < std::int32_t, std::ratio_divide>

...

years;

And there are exactly 12 months in a year: typedef std::chrono::duration < std::int32_t, std::ratio_divide>

...

months;

Now the definitions of years and months must be understood to be the average length, when converted to other units. But this is not so different than days being 24 hours: this is an average length of a day. No one is concerned that an average month is precisely 2,629,746 seconds long. However being able to say: assert(round<months>(jul/first/2013 - jan/first/2012).count() == 18); is arguably quite useful. Many financial calculations are done by the month (e.g. loan interest), even though the unit of "month" isn't as precisely defined as say "second". But with a round function things could "just work". template To round(const std::chrono::duration& d) { To t0 = std::chrono::duration_cast<To>(d); To t1 = t0; ++t1; auto diff0 = d - t0; auto diff1 = t1 - d; if (diff0 == diff1) { if (t0.count() & 1) return t1; return t0; } else if (diff0 < diff1) return t0; return t1; } I'm not positive, but I believe the latest C++14 additions would allow us to mark round with constexpr, making it that much more useful. For example we could then: static_assert(round<months>(jul/first/2013 - jan/first/2012).count() == 18, "Better be true!"); Howard

Rob Stewart

2:03 p.m.

On Apr 25, 2013, at 11:18 PM, Howard Hinnant wrote:

...

In addition to:

typedef std::chrono::duration < std::int32_t, std::ratio_multiply>

...
days;

One can then, taking the current definition of the civil (gregorian) calendar, create several more units which can be quite useful:

There are exactly 7 days in a week:

typedef std::chrono::duration < std::int32_t, std::ratio_multiply>

...
weeks;

There are exactly 146097 days in 400 years, which could rightly be called an era:

typedef std::chrono::duration < std::int32_t, std::ratio_multiply>

...
eras;

There are exactly 400 years in an era:

typedef std::chrono::duration < std::int32_t, std::ratio_divide>

...
years;

And there are exactly 12 months in a year:

typedef std::chrono::duration < std::int32_t, std::ratio_divide>

...
months;

Nice!

...

Now the definitions of years and months must be understood to be the average length, when converted to other units. But this is not so different than days being 24 hours: this is an average length of a day.

No matter how they are defined, they won't satisfy some set of users.

...

No one is concerned that an average month is precisely 2,629,746 seconds long.

I'm sure there is someone who is. ;)

...

However being able to say:

assert(round<months>(jul/first/2013 - jan/first/2012).count() == 18);

is arguably quite useful. Many financial calculations are done by the month (e.g. loan interest), even though the unit of "month" isn't as precisely defined as say "second". But with a round function things could "just work".

Even if there were different sets of definitions for different use cases, these are quite useful and interesting. One could imagine different namespaces for different sets of definitions: fin::month vs. sci::month, or whatever. ___ Rob (Sent from my portable computation engine)

Anurag Kalia

9:43 p.m.

...

One can then, taking the current definition of the civil (gregorian) calendar, create several more units which can be quite useful:

There are exactly 7 days in a week:

typedef std::chrono::duration < std::int32_t, std::ratio_multiply>

...
weeks;

There are exactly 146097 days in 400 years, which could rightly be called an era:

typedef std::chrono::duration < std::int32_t, std::ratio_multiply>

...
eras;

There are exactly 400 years in an era:

typedef std::chrono::duration < std::int32_t, std::ratio_divide>

...
years;

And there are exactly 12 months in a year:

typedef std::chrono::duration < std::int32_t, std::ratio_divide>

...
months;

Now the definitions of years and months must be understood to be the average length, when converted to other units. But this is not so different than days being 24 hours: this is an average length of a day.

This is almost magical! This definition of years gives me 43 years as the time since epoch, which is correct! Now given that these units are not the conventional duration of years or months, I don't think we benefit from exposing them to public, do we? Can we use these units in implementation when converting from JDN to Gregorian date? A user would want to use the construct year to either make a date where it would be an integer, or she/he would want to increment/decrement a date by a certain number of years, where it would be a duration. But we can provide them this functionality using a function and thereby not exposing this approximate year duration. If she/he happens to output an year otherwise, it would print 365.2425 which would only serve to confuse them, no?

...

No one is concerned that an average month is precisely 2,629,746 seconds long. However being able to say:

assert(round<months>(jul/first/2013 - jan/first/2012).count() == 18);

is arguably quite useful. Many financial calculations are done by the month (e.g. loan interest), even though the unit of "month" isn't as precisely defined as say "second". But with a round function things could "just work".

template To round(const std::chrono::duration& d) { To t0 = std::chrono::duration_cast<To>(d); To t1 = t0; ++t1; auto diff0 = d - t0; auto diff1 = t1 - d; if (diff0 == diff1) { if (t0.count() & 1) return t1; return t0; } else if (diff0 < diff1) return t0; return t1; }

I'm not positive, but I believe the latest C++14 additions would allow us to mark round with constexpr, making it that much more useful. For example we could then:

static_assert(round<months>(jul/first/2013 - jan/first/2012).count() == 18, "Better be true!");

Howard

I haven't compiled it yet, and I would report back with my findings, thank you! Thanks a lot for the support. I have uploaded a draft proposal to this Mailing List. Would you kindly check it for me? I am not sure if I should upload it twice. Thanks, Anurag.

Vicente J. Botet Escriba

27 Apr 27 Apr

2:42 a.m.

Le 26/04/13 23:43, Anurag Kalia a écrit :

...

...
One can then, taking the current definition of the civil (gregorian) calendar, create several more units which can be quite useful:

There are exactly 7 days in a week:

typedef std::chrono::duration < std::int32_t, std::ratio_multiply>

...
weeks; There are exactly 146097 days in 400 years, which could rightly be called an era:

typedef std::chrono::duration < std::int32_t, std::ratio_multiply>

...
eras; There are exactly 400 years in an era:

typedef std::chrono::duration < std::int32_t, std::ratio_divide>

...
years; And there are exactly 12 months in a year:

typedef std::chrono::duration < std::int32_t, std::ratio_divide>

...
months; Now the definitions of years and months must be understood to be the average length, when converted to other units. But this is not so different than days being 24 hours: this is an average length of a day. This is almost magical! This definition of years gives me 43 years as the time since epoch, which is correct! Now given that these units are not the conventional duration of years or months, I don't think we benefit from exposing them to public, do we? Can we use these units in implementation when converting from JDN to Gregorian date? In Boost.Chrono/Date I named them average_years and average_months.

A user would want to use the construct year to either make a date where it would be an integer, or she/he would want to increment/decrement a date by a certain number of years, where it would be a duration. But we can provide them this functionality using a function and thereby not exposing this approximate year duration. If she/he happens to output an year otherwise, it would print 365.2425 which would only serve to confuse them, no? No if it know we are talking of average years.

Thanks a lot for the support. I have uploaded a draft proposal to this Mailing List. Would you kindly check it for me? I am not sure if I should upload it twice.

Where the proposal is uploaded? Best, Vicente

Anurag Kalia

26 Apr 26 Apr

11:12 p.m.

I realize the fact that this is my second message and possibly very irritating. Sorry! (really) But I had an epiphany just now. Digging through boost docs, I saw in 'Appendices' > 'Future Notes' that they intend to release chrono::date on the basis of a proposal written by you! First of all, wow. Second of all, how concrete are those plans? They are included in boost docs themselves so I have doubts now if there is any room to modify the public interface. When I saw the given idea on boost gsoc page, I thought it was a reference point to go further. Now, do I have to implement the proposal as it is without minimal changes? Because, if yes, then I would have to change my proposal drastically, even after the fact that it is quite influenced by your paper itself. Thanks, Anurag Kalia.

Vicente J. Botet Escriba

27 Apr 27 Apr

2:54 a.m.

...

I realize the fact that this is my second message and possibly very irritating. Sorry! (really)

But I had an epiphany just now. Digging through boost docs, I saw in 'Appendices' > 'Future Notes' that they intend to release chrono::date on the basis of a proposal written by you! First of all, wow. Second of all, how concrete are those plans? They are included in boost docs themselves so I have doubts now if there is any room to modify the public interface. All this is ongoing work. Nothing is fixed and nothing is delivered on Boost.Chrono. And yes I would like to have Chrono/Date library in Boost, either based on my current interface, the one of Howard or yours if you reaches to get to finish a whole implementation with better interface. So no, the interface is not closed, but any proposal you could do would need to show it is a better interface.

When I saw the given idea on boost gsoc page, I thought it was a reference point to go further. Now, do I have to implement the proposal as it is without minimal changes? Because, if yes, then I would have to change my proposal drastically, even after the fact that it is quite influenced by your paper itself. As always it is up to you to make your proposal. You had the entry

Le 27/04/13 01:12, Anurag Kalia a écrit : points up to you to make a convincing proposal. Propose an interface, compare it with the existing ones, argument why do you go this way, ... Once thing is clear I would not mentor a project if I'm not confident with the competences of the student on the domain, know the problems and some solutions and has a clear vision of how the final library could look like. Of course during the project, things can and always will change, but we need a direction, a goal. HTH, Vicente

Anurag Kalia

9:08 a.m.

...

...
But I had an epiphany just now. Digging through boost docs, I saw in 'Appendices' > 'Future Notes' that they intend to release chrono::date on the basis of a proposal written by you! First of all, wow. Second of all, how concrete are those plans? They are included in boost docs themselves so I have doubts now if there is any room to modify the public interface. All this is ongoing work. Nothing is fixed and nothing is delivered on Boost.Chrono. And yes I would like to have Chrono/Date library in Boost, either based on my current interface, the one of Howard or yours if you reaches to get to finish a whole implementation with better interface. So no, the interface is not closed, but any proposal you could do would need to show it is a better interface.

Ok. I have uploaded the proposal anyway for review so you can see the inconsistencies. Yet, I would be scrutinising the two aforementioned proposals more closely for the next draft.

...

As always it is up to you to make your proposal. You had the entry points up to you to make a convincing proposal. Propose an interface, compare it with the existing ones, argument why do you go this way, ...

That is a relief. Because I do happen to (humbly) disagree with some design choices.

...

Once thing is clear I would not mentor a project if I'm not confident with the competences of the student on the domain, know the problems and some solutions and has a clear vision of how the final library could look like. Of course during the project, things can and always will change, but we need a direction, a goal.

May the best man win! May the boost win! :o) Anurag Kalia.

4215

Age (days ago)

4218

Last active (days ago)

List overview

Download

10 comments

5 participants

participants (5)

Anurag Kalia
Howard Hinnant
Howard Hinnant
Rob Stewart
Vicente J. Botet Escriba