Add duration parsing to core.time?

[Brad Anderson]

On Wednesday, 21 August 2013 at 06:46:49 UTC, Jonathan M Davis 
wrote:
> In general, I'm very much opposed to functions which try and 
> parse arbitrary
> strings as they're incredibly error-prone and have to guess at 
> what you mean.
> In pretty much any case where the string was emitted by a 
> computer in the first
> place rather than a human, that's just plain sloppy, and 
> ideally, a human
> would be required to put a string in a standard format when 
> inputting it (or
> input the values separately rather than as a string) in order 
> to avoid
> intepretation errors.
>
> - Jonathan M Davis

I agree completely and can speak from experience.  We used 
wxWidget's wxDateTime class for years at work and its 
ParseDateTime which allows free format strings. It was a source 
of never ending problems for us until we finally stopped using 
it.  The implementation was fine, it's just that dates are not 
amenable to unstructured reading. Date strings with locale 
information embedded in them may be doable but they are basically 
nonexistent.

Date strings are a lot like string encodings.  They are unsafe to 
use without knowing a definitive format/encoding.