ISO-8601, YYYY, yyyy, and why your year may be wrong
When designing a new API, it makes sense to consider this kind of thing: How are people going to use it, and how are people going to screw it up? Kids these days copy and paste everything so bugs tend to multiply if you (god forbid) make a popular API. Date formatter APIs are opaque and anyone trying to use one in the morning or before the 12th day of a month has to check the documentation, so what do we actually gain with this abstraction?<p>There's a small number of formats you might need that it makes sense to try to enumerate them:<p>* ISO8601 (and get it right, it's a comma not a dot)<p>* that weird ISO8601 variant that uses a dot<p>* kdb's .z.p<p>* DJB's TAI<p>* ISO/IEC 9899 asctime/ctime<p>* IEEE 1003.1 "ls" format<p>* Yankee-doodle format/other localised formats<p>* RFC1123/RFC7231<p>* RFC2109<p>* RFC822/RFC2822<p>* Fancy "X units since/until" relative time<p>Do you really need so many others that you should have "yyyy-MM-dd" anywhere in your code? Each of these are trivial to construct from a struct tm/Date object, that you'll end up with fewer bugs if you stop making up mini-languages for dates and just do it directly. Oh and your code will be faster.