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?
<snip>
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?
Moreover, the ease of use makes it a potential candidate for end-user applications, which
could pass the user-supplied format string straight to the library to deal with.
Just glancing at your scheme, it wouldn't be acceptable IMHO, because it
doesn't allow for arbitrary characters in the format specifier (such as
putting "hours" in there as a string).
I don't understand. How does what you're talking about differ from literals as given in
my spec?
It may be easy to use, but on a cursory
inspection at least, it doesn't seem to be anywhere near powerful enough.
You tell me what features you want adding, and I'll see if I can find a good
way to add them.
Anyway, I guess I might as well post here the rationale I wrote earlier.
----------
Many APIs and applications that deal with dates and times include some mechanism for
formatting them according to a custom format. Often, this mechanism involves supplying a
format string.
However, the format of these format strings is normally specific to the application or
API. Here are just a few examples:
- the to_char function in Oracle and PostgreSQL
- the PHP date function
- date formatting in Microsoft Excel
- the C standard library strftime function
- the Acorn Archimedes clock application
Many of these systems have their drawbacks, such as complexity, lack of features, or lack
of consistency. These can affect both the ease of using the system and the ease of
implementing it. PHP's system is simple in comparison, but this simplicity (achieved by
making each format specifier a single letter) comes at the expenses of extensibility and
memorability.
Moreover, intellectual property concerns aside, using a pre-existing format string system
would pose the challenge of deciding which one to use. There haven't as far as I know
been any attempts to create an open standard for them. Another difficulty with using a
pre-existing one is that to add more formatting options I would be creating a fork of the
system, and then as my fork and the original diverge there may be format strings with
different meanings in the two systems, potentially leading to user confusion.
As such, devising a new format string system for my library has turned out to be the way
to go. In doing so, I have designed it to avoid the weaknesses I found in the other systems.
My system has a number of strengths:
- Power - Currently there are 50 format specifiers, compared to PHP's 37. Add to that
alignment fields and collapsible portions, which were my own idea.
- Logic - The concept of letters distinguishing pieces of information, and lengths and
capitalisations distinguishing the ways in which the same piece of information can be
formatted, is a nice logical system.
- Naturality - This helps to make format strings human-readable.
- Extensibility - Plenty of room for more format specifiers to be added in a
later version.
- Simplicity - The boundaries between format specifiers are straightforwardly defined,
making the system easier to understand and implement than (say) the Oracle system.
- Memorability - It's far easier to remember a relationship between letters and the data
they represent than to memorise all the more diverse Oracle codes or PHP's
put-it-where-it-fits single-letter specifiers.
- Backward/forward compatibility - Unrecognised format specifiers are illegal - no
silently treating them as literals, which may cause the behaviour to change between versions.
----------
Stewart.
