gerritbot added a comment.
Change 868173 **merged** by jenkins-bot:
[pywikibot/core@master] [Feature] Allow normalization of WbTime objects
https://gerrit.wikimedia.org/r/868173
TASK DETAIL
https://phabricator.wikimedia.org/T123888
EMAIL PREFERENCES
gerritbot added a comment.
Change 868173 had a related patch set uploaded (by RPI2026F1; author:
RPI2026F1):
[pywikibot/core@master] [Feature] Allow normalization of WbTime objects
https://gerrit.wikimedia.org/r/868173
TASK DETAIL
https://phabricator.wikimedia.org/T123888
EMAIL
RPI2026F1 added a comment.
Actually I think normalization would help solve the problem. The fix then is
simple.
TASK DETAIL
https://phabricator.wikimedia.org/T123888
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: RPI2026F1
Cc: RPI2026F1,
RPI2026F1 added a comment.
Would `approximately_equal` be a good method name?
TASK DETAIL
https://phabricator.wikimedia.org/T123888
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: RPI2026F1
Cc: RPI2026F1, thiemowmde, Multichill, Aklapper,
thiemowmde added a comment.
> the values are //not// actually the same.
They are not identical, but equal for all practical purposes. It's possible
to have both concepts next to each other in the same codebase. As you suggested
it's a good idea to make the distinction visible via
RPI2026F1 added a comment.
> For example, if the precision is set to "month", the values 2017-04-00 and
2017-04-01 and even 2017-04-25 are all the same and should all return true in a
comparison.
In terms of OOP this is a bad idea because the values are //not// actually
the same. Maybe
