Steven D'Aprano <steve+pyt...@pearwood.info> added the comment:
> > ISO 8601 specifies dozens of ways to represent the same datetime
>
> Yes, but not within the same format. If someone were to choose the
> format '2014-04-10T24:00:00', they would have a reasonable expectation
> that there is only one unique string that corresponds with that
> datetime.
There are no format code in '2014-04-10T24:00:00', it cannot be a
format. Without knowing the format, there is no way of telling what that
string represents or whether it is a unique representation.
- Is the leading 0 in '04' mandatory or optional?
- Could the '00's be replaced by '0' or even left out altogether?
- Is 24:00:00 the exact same time as 00:00:00?
- If the final '00' represents seconds, does it accept microseconds '.000'?
> > As far as the inconsistency, I think that's an argument for being
> > less strict, not more, and allowing non-ASCII digits in more places
> > not just the first. Why shouldn't (let's say) a Bengali user specify
> > the day of the month using Bengali digits?
>
> That's an interesting direction. It might be a good thing to allow
> users in different locales to specify datetime with their native
> digits. But, if we were to go in that direction, we would have to:
>
> 1. Define that use case more rigorously, consider whether it has any
> effects we need to consider, like clashes with how the local culture
> expresses dates.
I don't think so. Supporting different calendars is a seperate, and far
more complex issue, than just supporting dumb transliteration of
Hindu-Arabic digits 0...9 into other character sets.
This makes datetime behave more like int(), float(), etc, all of which
accept non-ASCII digits including (e.g.) East-Asian double-width digits.
py> int('５４３２')
5432
Supporting non-Western calendars is a worthy thing, but probably best
left for a third-party library.
> 2. Enable it in other fields except year.
That part is easy: replace `[0-9]` in regexes with `\d`.
> 3. Add tests for it.
Aye, that would need to be done. Adding the tests would be the hard
part.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue39280>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
