std.dateparse reincarnation

Jonathan M Davis jmdavisProg at gmx.com
Tue Oct 25 18:44:21 PDT 2011


On Wednesday, October 26, 2011 01:54:22 Stewart Gordon wrote:
> On 25/10/2011 22:22, Jonathan M Davis wrote:
> <snip>
> 
> > At minimum, as I understand it, C, Java, python, and Ruby all have
> > similar date/time formatting facilities and use mostly the same flags
> > for date/time formatting.
> 
> If they're only _similar_, it isn't really a standard.  Indeed, it seems to
> me a potential cause of confusion if these systems, with the same same look
> and feel and mostly the same format specifiers, have subtle differences. 
> Moreover, how do these APIs deal with an unrecognised format specifier?

I have not looked over them in detail, but from what I've seen, they're _very_ 
similar - as in they took the C format specifiers and followed them in almost 
all (and maybe even all) cases but added a few of their own. But slight 
differences between them alone don't merit creating a whole new way of 
formatting dates and times.

> >  There's a lot to be gained by doing something standard and so any
> >  major
> > 
> > deviations from strftime need to be solid improvements over strftime for
> > them to be acceptable.
> 
> My system is both much easier to remember and more extensible than strftime.
>  Does either of these constitute a solid improvement?

I have yet to look over your API in great detail, but from what I saw, it 
looked like _all_ alpha characters were considered flags, whereas strftime uses 
% to distinguish flags from other characters, just like printf and writeln do. 
I'll look over your API in more detail, but I would consider that a deal 
breaker if that's what it does. There may very well be other things that 
you've done with it which are worth drawing from, but I fully intend to use 
flags like strftime does. Not doing so is unduly restrictive to what you can 
put in a format specifier. It should be possible to put arbitrary strings in 
the format specifier just like you would with printf or writeln.

- Jonathan M Davis


More information about the Digitalmars-d-announce mailing list