You can clone with
HTTPS or Subversion.
I don't know why you invented your own format specifiers, but things like stftime (and that family of methods) have a well known set of format specifiers. Would be nice if you could just use those instead of making new ones which won't match up to what someone may already be using.
There are too many different date format tokens syntaxes for me to match any standard.
See this comment. #36 (comment)
That explains my rationale for why I chose the tokens I did.
I would think using the strftime notation would be quite reasonable as it would be found on all platforms in some form. The fact that things like unix, python, php, ruby, c/c++, etc all support it should tell you something :)
When looking for a simple date library to use over the builtin one, I would pick something that mimics strftime or just not bother personally.
The intention of this library is not to port strftime. It is to provide a safe and robust collection of common functionality regarding dates.
I'm not too experienced with formatting dates in unix, python, ruby, or c++, but I know php has both strftime and date for formatting dates, and the tokens for those functions vary wildly.
As described in the comment I linked to above, the reason I chose the tokens I did was to aid readability. I believe the tokens I chose would be much easier to remember or deduce than strftime tokens for someone who hasn't been exposed to either.
I don't mean to start an argument, hopefully you can understand my rationale for designing the library this way.
As you can see, it exposes the strftime syntax for date/time/datetime formatting, which the client-side code can use at will.
Not trying to reverse your decision, since your reasoning makes sense to me, but just providing a use case.
docs for #49