Proposal for custom time string formatting in std.datetime

Stewart Gordon smjg_1998 at yahoo.com
Thu Dec 22 04:59:15 PST 2011


On 22/12/2011 03:41, Jonathan M Davis wrote:
<snip>
> http://jmdavis.github.com/d-programming-language.org/std_datetime.html

Have I got all this right?

- a flag goes from % up to another %, a {, a whitespace or punctuation character
- flags with [...] portions are exceptions to this rule, extending to the closing ]
- %{ or %} is a literal { or }
- all literal characters that aren't classed as whitespace or punctuation must be enclosed 
in {...}
- {%} is just a literal %
- in %C2* and %Cn* flags, C must be either _ (space) or 0


To look at the detail:

- In %nY, does "up to n" mean that it truncates years longer than that to that many 
characters?  Does it strip any leading 0s that result from this truncation?  (Under %3Y, 
does 2011 become 11 or 011?)

- But the approach to formatting the year is nicely systematic.  (I've thought of possibly 
adding to my scheme a means of formatting dates to arbitrary length with sign, in order to 
support the ISO format for years that may be outside the 1BC-9999 range.

- If you're going to have the ISO week number in the system, it seems to me you should 
also have the week-numbering year.  (I've thought about possibly adding these to my scheme.)

- In %F, What does "as many digits as necessary" mean?  In particular, why in the example 
code does it give 12/100000 and not 3/25000 despite the latter being shorter?

- Can only literal stuff be included within %BC[...] and %AD[...]?

- %cond and %func - I'm made to wonder to what extent this would be used and to what 
extent it would just be simpler to use if / ?: / ~.  Anyway, I assume that if there's more 
than one, they will reference the template arguments in order.  Can %cond contain other 
%*[...] flags?  Indeed, can %cond's be nested to arbitrary depth?

- Does %localeDate give the short or the long date format?  (This and %localeTime are 
handled by separate functions in my library - I didn't think there was any real use case 
for including such a thing within a longer formatted date/time string.)


On the whole, it seems a powerful system.  The format strings can get quite obfuscated, 
but at least the flags that are likely to be commonly used aren't too bad.

It seems strange to require explicit notations both for flags and for alphanumeric 
literals.  But I suppose it makes the literals easier to read than having to follow where 
all those % signs are.

One thing I noticed doesn't appear in your scheme is ordinal suffix.  OK, so arbitrary 
alignment fields and collapsible portions aren't to be seen either, but those are quite 
rare in format string schemes anyway.

Stewart.


More information about the Digitalmars-d mailing list