On Mon, Feb 4, 2019 at 10:53 AM Avi Gross <avigr...@verizon.net> wrote: > It is very bad form to have ambiguous compressed formats. Even if you include > a slash or minus sign or period or the delimiter of your choice, I sometimes > see this: > > 01/02/2020 > > And I wonder if it is meant to be January 2nd or February 1st. > > Clearly 30/01/2020 cannot be the 30th month so it must be an alternate > format. And, years from now, we may get a year that might confuse us more if > compressed like:
The only sane way is to have the components in some sort of reasonable order. Day-Month-Year is better than Month-Day-Year, though Year-Month-Day is better than both. > 21121221 > > Is that 2112 as the year an Dec 21? Sure it is. What else would it be? Without delimiters, the only recognized format is year-month-day. > In the interest of clarity, how is this different than including a time zone > alongside a time value? Maybe '0Q" is silly, but a prefix or suffix or even a > new delimiter might be a good idea. Are any available? > Attach a "Z" at the very end (after the time, which you'll probably have if you care about timezones). ISO 8601 format. If you need to attach some *other* time zone (which should be rare - ONLY do this if you absolutely cannot translate to UTC), write the date and time, then add a space, and the IANA tzdata in the "Region/City" format eg "Australia/Melbourne" or "America/New_York". Avoid the abbreviations like "EST" as they are ambiguous (horrifically so in the cases of "CST" and "BST"). ChrisA -- https://mail.python.org/mailman/listinfo/python-list
