std.dateparse reincarnation

[Stewart Gordon]

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.