On Monday 15 June 2009 19:42:18 Stewart, Robert wrote: [snip]
Having said that, I recognize your point about time durations versus time points. If the suggested change only applies to time durations and not to time points, of which I have no idea, I'd be much less concerned.
Exactly, I'm speaking of durations only. Time points won't be affected.
2. An exception is not a good choice to highlight the problem, since in most cases it will be swallowed by IO streams. In practice streaming errors (in form of failbit or badbit) are often ignored, and Boost.DateTime is an example. And ios_base::failure usually isn't as descriptive as what is being initially thrown.
Sorry, but no. The default is for IOStreams to set the stream state to indicate failures, but that doesn't absorb exceptions from code such as we're discussing and convert exceptions into stream state.
It does adsorb exceptions, at least on my GCC 4.3.2. But it does pass through original exceptions if exceptions are enabled, but I'm not sure it's guaranteed by the standard. You can play with the attached code sample to test your platform.
3. The caller has to check the arguments. It's the bottom line of both STL and most C functions. Extensive error checking may be provided but it should be optional. An assert fits perfectly.
A well designed library prevents misuse.
Right. But since DateTime IO is based on facets, there isn't much room for design decisions. As for the exception, it does not prevent misuse. It *may* show when the feature *have been* misused.
That's an argument for changing the default formatting, I grant. It's also an argument for throwing an exception rather than silently truncating if the default formatting isn't changed for other reasons. Yes, folks must use libraries correctly. In C libraries, the functions return error codes which can be ignored. In C++, we have exceptions at our disposal. Furthermore, there are many developers who don't spend much time with debug builds and there are many usage scenarios that can arise untested. The library shouldn't misbehave silently in those cases.
We can debate on this. There are people that prefer safety at all costs. There are other people, including me, that don't want to pay for unnecessary run time checks. My position is that there are no guarantees if the code is used incorrectly. If I want safety, I do the proper testing, including debug builds and invalid input to my system to verify that it tackles it well. One advantage of the assert is that it can satisfy both safety and performance needs.
I don't have a C standard on me, but I'm almost sure it doesn't specify %O.
Every online strftime manpage I checked, such as the following, describes %O:
http://www.opengroup.org/onlinepubs/007908799/xsh/strftime.html
I guess, %O was not a good choice in the first place, then. I'm not inclined to change it now, but the final call is after the library maintainer.
I haven't looked at the implementation, but I assume that DateTime is interpreting the specifiers itself.
No, at least, not all of them. In the end it comes down to call to strftime, last time I checked.
In my mind, that justifies my trying to map to strftime() behavior.
I'd consider strftime as an implementation detail.