RetroBBS - comp.lang.python - Pre-Pre-PEP: The datetime.timedeltacal class

Pre-Pre-PEP: The datetime.timedeltacal class

<mailman.131.1650130553.20749.python-list@python.org>

https://www.rocksolidbbs.com/devel/article-flat.php?id=22293&group=comp.lang.python#22293

copy link Newsgroups: comp.lang.python

Path: i2pn2.org!i2pn.org!aioe.org!news.mixmin.net!news2.arglkargh.de!news.karotte.org!fu-berlin.de!uni-berlin.de!not-for-mail
From: hjp-python@hjp.at (Peter J. Holzer)
Newsgroups: comp.lang.python
Subject: Pre-Pre-PEP: The datetime.timedeltacal class
Date: Sat, 16 Apr 2022 19:35:51 +0200
Lines: 100
Message-ID: <mailman.131.1650130553.20749.python-list@python.org>
References: <20220416173551.fk6voaa3o25iuewm@hjp.at>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
protocol="application/pgp-signature"; boundary="xindxvgpvy7u3jv5"
X-Trace: news.uni-berlin.de 1Fr3PE7rsIgVOfxjFv9KXgUD9pRO9BGZnzzm0k6xvdLQ==
Return-Path: <hjp-python@hjp.at>
X-Original-To: python-list@python.org
Delivered-To: python-list@mail.python.org
Authentication-Results: mail.python.org; dkim=none reason="no signature";
dkim-adsp=none (unprotected policy); dkim-atps=neutral
X-Spam-Status: OK 0.000
X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; '(e.g.': 0.05; 'content-
type:multipart/signed': 0.05; 'happened': 0.07; 'compute': 0.09;
'content-type:application/pgp-signature': 0.09; 'datetime': 0.09;
'filename:fname piece:asc': 0.09; 'filename:fname
piece:signature': 0.09; 'filename:fname:signature.asc': 0.09;
'float': 0.09; "hasn't": 0.09; 'proposing': 0.09; "shouldn't":
0.09; 'smaller': 0.09; 'subject:class': 0.09; 'typically': 0.09;
'"computer': 0.16; '"creative': 0.16; '(unless': 0.16; '__/':
0.16; 'arithmetic': 0.16; 'backward': 0.16; 'challenge!"': 0.16;
'constructor': 0.16; 'daylight': 0.16; 'from:addr:hjp-python':
0.16; 'from:addr:hjp.at': 0.16; 'from:name:peter j. holzer': 0.16;
'hjp@hjp.at': 0.16; 'holzer': 0.16; 'hours,': 0.16; 'impossible':
0.16; 'instead.': 0.16; 'objects.': 0.16; 'reality.': 0.16;
'rough': 0.16; 'semantics': 0.16; 'separately,': 0.16; 'stick':
0.16; 'stross,': 0.16; 'subject:Pre': 0.16; 'subject:skip:d 20':
0.16; 'time",': 0.16; 'unlikely': 0.16; 'url-
ip:212.17.106.137/32': 0.16; 'url-ip:212.17.106/24': 0.16; 'url-
ip:212.17/16': 0.16; 'url:hjp': 0.16; '|_|_)': 0.16; 'problem':
0.16; 'code.': 0.17; 'probably': 0.17; "can't": 0.17;
'subscribed': 0.19; "aren't": 0.19; 'to:addr:python-list': 0.20;
'feedback': 0.23; 'weeks': 0.23; 'seems': 0.26; 'intend': 0.26;
'library': 0.26; 'months,': 0.26; 'object': 0.26; 'bit': 0.27;
'function': 0.27; 'done': 0.28; 'mostly': 0.28; 'sense': 0.28;
'takes': 0.31; 'think': 0.32; "doesn't": 0.32; 'gathering': 0.32;
'minutes,': 0.32; 'same,': 0.32; 'specified': 0.32; 'split': 0.32;
'weeks,': 0.32; "wouldn't": 0.32; 'but': 0.32; "i'm": 0.33;
"i'll": 0.33; 'there': 0.33; 'months': 0.35; 'currently': 0.37;
"it's": 0.37; 'class': 0.37; 'hard': 0.37; 'could': 0.38; 'two':
0.39; 'added': 0.39; 'adding': 0.39; 'least': 0.39; 'handle':
0.39; 'subject:PEP': 0.39; 'break': 0.39; 'seconds': 0.40;
'something': 0.40; 'should': 0.40; 'likely': 0.61; 'method': 0.61;
'finally': 0.62; 'received:212': 0.62; 'here': 0.62; 'days': 0.62;
'hours': 0.63; 'between': 0.63; 'research': 0.64; 'years': 0.65;
'received:userid': 0.66; 'day': 0.66; 'right': 0.68; 'days,':
0.69; 'stores': 0.69; 'url-ip:212/8': 0.69; 'varying': 0.69;
'rules': 0.70; 'subject:The': 0.70; 'deal': 0.73; 'plus': 0.73;
'zone': 0.76; '"fix"': 0.84; 'direction.': 0.84; 'leap': 0.84;
'received:at': 0.84; 'represented': 0.84; 'savings': 0.84;
'opposite': 0.91; 'somebody': 0.91
Mail-Followup-To: python-list@python.org
Content-Disposition: inline
X-BeenThere: python-list@python.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: General discussion list for the Python programming language
<python-list.python.org>
List-Unsubscribe: <https://mail.python.org/mailman/options/python-list>,
<mailto:python-list-request@python.org?subject=unsubscribe>
List-Archive: <https://mail.python.org/pipermail/python-list/>
List-Post: <mailto:python-list@python.org>
List-Help: <mailto:python-list-request@python.org?subject=help>
List-Subscribe: <https://mail.python.org/mailman/listinfo/python-list>,
<mailto:python-list-request@python.org?subject=subscribe>
X-Mailman-Original-Message-ID: <20220416173551.fk6voaa3o25iuewm@hjp.at>

by: Peter J. Holzer - Sat, 16 Apr 2022 17:35 UTC

Attachments: signature.asc (application/pgp-signature)

I intend to take this to python-ideas, but I'm not currently subscribed
there and I think I should probably do a bit of research before
proposing something over there. So I'll start by gathering some feedback
here with a rough sketch.

Datetime arithmetic in the real world is typically not done in seconds,
but in calendaric units: Hours, days, weeks, months, years, ...
The problem is that several of these have varying lengths:

* 1 minute may be 60 or 61 seconds (theoretically also 59, but that
hasn't happened yet).
* 1 day can be 23, 24 or 25 hours (unless you are in Troll, Antarctica,
where it's even weirder).
* 1 month may be 28, 29, 30 or 31 days (let's stick to the Gregorian
calendar)

The standard library has a datetime.timedelta class which does store
days and seconds separately, so somebody seems to have had the right
idea, but the normalization rules make it impossible to distinguish
between "1 day plus 1 hour" and "25 hours", and it doesn't deal with
months at all.

Technically it shouldn't be too hard to "fix" timedelta, but that
wouldn't be backward compatible and would very likely break existing
code.

Therefore a new class (provisionally called timedeltacal, because it is
calendaric, not absolute) should be added to datetime:

Internally it stores months, days, seconds and microseconds as ints.

The seconds and microseconds split is mostly for compatibility with
datetime and timedelta. We could store seconds as a float instead.

We don't store minutes since leap seconds aren't usually represented in
"computer time", so they are unlikely to be useful in a timedeltacal
object.

Days are stored since they aren't a fixed multiple of any smaller unit.
Months are stored since they aren't a fixed multiple of any smaller unit.

Hours, weeks and years aren't stored since they are always 60 minutes, 7
days and 12 months respectively.

When adding a timedeltacal object to a datetime, the fields are added
from most to least significant: First a new date is computed by
advancing the number of months specified [TODO: Research how other
systems handle overflow (e.g. 2022-01-31 + 1 month: 2022-02-31 doesn't
exist)], then advance the number of days. Finally add the number of
seconds and microseconds, taking into accout daylight savings time
switches if the datetime is time zone aware.

Subtracting a timedeltacal object from a datetime is the same, just in
the opposite direction.

Note that t + d - d is in general not equal to t.

We can't cnange the semantics of datetime - datetime, so there must be a
function to compute the difference between to datetimes as a
timedeltacal. It could be a method on datetime (maybe t.sub(u) for t-u
like in Go) or a constructor which takes two datetime objects.

In any case I think that u + (t - u) == t should hold. [TODO: Check that
this is possible]

Attachments: signature.asc (application/pgp-signature)

The meek are contesting the will.

devel / comp.lang.python / Pre-Pre-PEP: The datetime.timedeltacal class

devel / comp.lang.python / Pre-Pre-PEP: The datetime.timedeltacal class

Subject	Author
Pre-Pre-PEP: The datetime.timedeltacal class	Peter J. Holzer