Proposal for custom time string formatting in std.datetime

[Jonathan M Davis]

On Friday, December 23, 2011 10:26:05 Stewart Gordon wrote:
> To quote directly from the spec of my scheme:
> "Each specifier is a letter, or two or more of the same letter consecutively
> (picked out by maximal munch before lookup in the following table)."
> So this is a non-issue.

So, your flags are even more restrictive than I understood them to be. You 
can't have multiple-character flags unless they're the same letter. I thought 
that you could. That _does_ avoid the problem that I was describing, but the 
result is too limiting IMHO. It certainly makes it hard to add flags for 
specific formats similar to %ctime or %mpeg7. It also means that you can't 
reuse letters.

> > It can definitely work, but the more
> > flags that you have, the more problematic it becomes. It's also easier
> > to
> > separate out consecutive flags when reading them if you have %.
> 
> Here's the little bit of code in my library that finds the end of a flag:
> 
>      char letter = cast(char) std.ctype.tolower(*charPos);
>      CPtr!(char) beginSpec = charPos;
> 
>      do {
>          ++charPos;
>      } while (std.ctype.tolower(*charPos) == letter);
> 
> Seems to me pretty straightforward.

The situation would be very different if you allowed multi-character flags of 
varying letters like I thought you did.

> >>> It's an interesting approach, but it isn't as
> >>> flexible as it could be because of its use of maximul munch instead
> >>> of % flags.
> >> 
> >> How do you mean?
> > 
> > It's harder to have modifiers for flags without the %. For instance,
> > what I'm doing with filler characters would be much more difficult with
> > your scheme. With % delineating the flags, it becomes easier to handle
> > that sort of thing.
> <snip>
> 
> What are you doing with filler characters?  It appears to me, just allowing
> space or 0 as a filler character in some flags.  In my system, alignment
> fields provide a more powerful way of doing the same thing.

There's also the question of indicating the number of digits in the flag. In 
mine, it's quite easy to indicate either the exact number of digits that the 
result of the flag must be or to indicate that it must be _at least_ that many. 
And it's very consistent across flags. In yours, you have to do it with the 
casing of the letters, since the letters are all you have to work with. You 
have no modifiers. It may be that your alignment fields do a better job than the 
filler characters that I'm using, but I'd have to read over your spec again. I 
do remember thinking that the alignment fields didn't really add enough over 
using filler characters to be worth the extra complication.

It's possible that your scheme is somewhat easier to use for the most basic 
cases, but as soon as more specific and/or complicated schemes are needed (e.g. 
mpeg-7 or any of the ISO schemes), I don't think it works as well in general. 
I was trying to create a scheme that was flexible and powerful enough to do 
those more complicated schemes and yet still be easily usable for basic stuff. 
And I don't think that I'm all that far off from that, but it's quite possible 
that that extra power is making mine harder to use than yours for the most 
basic cases. I don't know.

- Jonathan M Davis