Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

An economist is a man who would marry Farrah Fawcett-Majors for her money.


devel / comp.lang.python / Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?

SubjectAuthor
* Why does datetime.timedelta only have the attributes 'days' and 'seconds'?Loris Bennett
+* Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?Loris Bennett
|+* Re: Why does datetime.timedelta only have the attributes 'days' andPaul Bryan
||`* Re: Why does datetime.timedelta only have the attributes 'days' andJon Ribbens
|| +* Re: Why does datetime.timedelta only have the attributes 'days' andMRAB
|| |`- Re: Why does datetime.timedelta only have the attributes 'days' andJon Ribbens
|| +- Re: Why does datetime.timedelta only have the attributes 'days' andMarco Sulla
|| +- Re: Why does datetime.timedelta only have the attributes 'days' andChris Angelico
|| `* Re: Why does datetime.timedelta only have the attributes 'days' andPeter J. Holzer
||  `* Re: Why does datetime.timedelta only have the attributes 'days' andJon Ribbens
||   +* Re: Why does datetime.timedelta only have the attributes 'days' andJon Ribbens
||   |+* Re: Why does datetime.timedelta only have the attributes 'days' andPeter J. Holzer
||   ||`* Re: Why does datetime.timedelta only have the attributes 'days' andJon Ribbens
||   || +* Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?Dennis Lee Bieber
||   || |`- Re: Why does datetime.timedelta only have the attributes 'days' andJon Ribbens
||   || +- Re: Why does datetime.timedelta only have the attributes 'days' andChris Angelico
||   || `* Re: Why does datetime.timedelta only have the attributes 'days' andPeter J. Holzer
||   ||  `* Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?Loris Bennett
||   ||   `* Re: Why does datetime.timedelta only have the attributes 'days' andJon Ribbens
||   ||    `* Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?Loris Bennett
||   ||     `* Re: Why does datetime.timedelta only have the attributes 'days' andJon Ribbens
||   ||      +* Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?Loris Bennett
||   ||      |+* Re: Why does datetime.timedelta only have the attributes 'days' andJon Ribbens
||   ||      ||`- Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?Loris Bennett
||   ||      |`* Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?Dennis Lee Bieber
||   ||      | +* Re: Why does datetime.timedelta only have the attributes 'days' andBarry
||   ||      | |`- Re: Why does datetime.timedelta only have the attributes 'days' andJon Ribbens
||   ||      | `* Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?Loris Bennett
||   ||      |  `- Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?Mark Lawrence
||   ||      `- Re: Why does datetime.timedelta only have the attributes 'days' andMRAB
||   |+- Re: Why does datetime.timedelta only have the attributes 'days' andChris Angelico
||   |+- Re: Why does datetime.timedelta only have the attributes 'days' andPeter J. Holzer
||   |+- Re: Why does datetime.timedelta only have the attributes 'days' andChris Angelico
||   |+- Re: Why does datetime.timedelta only have the attributes 'days' andPeter J. Holzer
||   |+- Re: Why does datetime.timedelta only have the attributes 'days' andChris Angelico
||   |+- Re: Why does datetime.timedelta only have the attributes 'days' andPeter J. Holzer
||   |`- Re: Why does datetime.timedelta only have the attributes 'days' andChris Angelico
||   +* Re: Why does datetime.timedelta only have the attributes 'days' andPeter J. Holzer
||   |`- Re: Why does datetime.timedelta only have the attributes 'days' andJon Ribbens
||   +- Re: Why does datetime.timedelta only have the attributes 'days' andChris Angelico
||   `* Re: Why does datetime.timedelta only have the attributes 'days' andRandom832
||    `- Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?Loris Bennett
|`- Re: Why does datetime.timedelta only have the attributes 'days' andLars Liedtke
`- Re: Why does datetime.timedelta only have the attributes 'days' andChris Angelico

Pages:12
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?

<slrnt5mhvp.7j14.jon+usenet@raven.unequivocal.eu>

 copy mid

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

 copy link   Newsgroups: comp.lang.python
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: jon+use...@unequivocal.eu (Jon Ribbens)
Newsgroups: comp.lang.python
Subject: Re: Why does datetime.timedelta only have the attributes 'days' and
'seconds'?
Date: Sat, 16 Apr 2022 22:49:29 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 22
Message-ID: <slrnt5mhvp.7j14.jon+usenet@raven.unequivocal.eu>
References: <mailman.87.1649948491.20749.python-list@python.org>
<slrnt5gf1l.41c.jon+usenet@raven.unequivocal.eu>
<20220416084411.kkfjtz2bjl5wqo5o@hjp.at>
<mailman.123.1650098653.20749.python-list@python.org>
<slrnt5li7k.41c.jon+usenet@raven.unequivocal.eu>
<slrnt5lk8c.41c.jon+usenet@raven.unequivocal.eu>
<20220416160028.tmedahn64gdpzsov@hjp.at>
<mailman.127.1650124831.20749.python-list@python.org>
<slrnt5ma4a.41c.jon+usenet@raven.unequivocal.eu>
<rtfm5hlf446gq0m1o67htu0v5i09r3532t@4ax.com>
Injection-Date: Sat, 16 Apr 2022 22:49:29 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="02788739bd5d73c921a20c08f6b68379";
logging-data="16886"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/ATSfnFbHRVfRTzALWVh2ZbvXhM59zSjc="
User-Agent: slrn/1.0.3 (Linux)
Cancel-Lock: sha1:R+52sfIeuMKghrkklDSgy6WrYds=
 by: Jon Ribbens - Sat, 16 Apr 2022 22:49 UTC

On 2022-04-16, Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:
> On Sat, 16 Apr 2022 20:35:22 -0000 (UTC), Jon Ribbens
><jon+usenet@unequivocal.eu> declaimed the following:
>>I can categorically guarantee you it is not. But let's put it a
>>different way, if you like, if I want to add 24 hours, i.e. 86,400
>>seconds (or indeed any other fixed time period), to a timezone-aware
>>datetime in Python, how do I do it? It would appear that, without
>>converting to UTC before doing the calculation, you can't.
>
> Which is probably the recommended means to do just that.

Yes, as I've already mentioned it is good advice to always use UTC
when doing date/time calculations and only convert to another timezone
for display. However it is somewhat surprising that Python's datetime
simply *does not work* when doing arithmetic on timezone-aware objects.
It's not "disrecommended", it's straight-up broken.

> The only thing that is most noticeable about UTC is the incorporation
> of leap-seconds.

I've never yet managed to find an application where leap-seconds matter
;-)

Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?

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

 copy mid

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

 copy link   Newsgroups: comp.lang.python
Path: i2pn2.org!i2pn.org!news.swapon.de!fu-berlin.de!uni-berlin.de!not-for-mail
From: ros...@gmail.com (Chris Angelico)
Newsgroups: comp.lang.python
Subject: Re: Why does datetime.timedelta only have the attributes 'days' and
'seconds'?
Date: Sun, 17 Apr 2022 08:53:36 +1000
Lines: 26
Message-ID: <mailman.145.1650149629.20749.python-list@python.org>
References: <mailman.87.1649948491.20749.python-list@python.org>
<slrnt5gf1l.41c.jon+usenet@raven.unequivocal.eu>
<20220416084411.kkfjtz2bjl5wqo5o@hjp.at>
<mailman.123.1650098653.20749.python-list@python.org>
<slrnt5li7k.41c.jon+usenet@raven.unequivocal.eu>
<slrnt5lk8c.41c.jon+usenet@raven.unequivocal.eu>
<20220416160028.tmedahn64gdpzsov@hjp.at>
<mailman.127.1650124831.20749.python-list@python.org>
<slrnt5ma4a.41c.jon+usenet@raven.unequivocal.eu>
<rtfm5hlf446gq0m1o67htu0v5i09r3532t@4ax.com>
<CAPTjJmqoUnmMp-8sm2REy8yPWw2FzYVU064-RDFO1AdEGgoX0g@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
X-Trace: news.uni-berlin.de skEqgOcoIoQrr8FXYo40Dg2EgsbKTsA3ZWafxoNX99ow==
Return-Path: <rosuav@gmail.com>
X-Original-To: python-list@python.org
Delivered-To: python-list@mail.python.org
Authentication-Results: mail.python.org; dkim=pass
reason="2048-bit key; unprotected key"
header.d=gmail.com header.i=@gmail.com header.b=qu1aVoOV;
dkim-adsp=pass; dkim-atps=neutral
X-Spam-Status: OK 0.020
X-Spam-Evidence: '*H*': 0.96; '*S*': 0.00; '2022': 0.05; 'despite':
0.05; 'subject:Why': 0.07; 'sun,': 0.07; 'anyway,': 0.09;
'minute,': 0.09; 'reasons:': 0.09; '4-5': 0.16; 'anyway.': 0.16;
'anywhere.': 0.16; 'chrisa': 0.16; 'figures,': 0.16;
'from:addr:rosuav': 0.16; 'from:name:chris angelico': 0.16;
'noon': 0.16; 'region,': 0.16; 'subject:does': 0.16;
'subject:seconds': 0.16; 'synchronize': 0.16; 'wrote:': 0.16;
"aren't": 0.19; 'proposals': 0.19; 'round': 0.19; 'to:addr:python-
list': 0.20; "isn't": 0.27; 'bit': 0.27; 'message-
id:@mail.gmail.com': 0.32; 'but': 0.32; 'mean': 0.34; 'header:In-
Reply-To:1': 0.34; 'received:google.com': 0.34; 'subject:skip:d
10': 0.35; 'close': 0.35; 'from:addr:gmail.com': 0.35; 'year':
0.36; "it's": 0.37; 'received:209.85': 0.37; 'read': 0.38;
'received:209': 0.39; 'calendar': 0.40; 'exact': 0.40; 'want':
0.40; 'should': 0.40; 'remember': 0.61; 'days': 0.62; 'hours':
0.63; 'down': 0.64; 'during': 0.69; 'june': 0.73; 'subject:have':
0.75; 'adjustment.': 0.84; 'location.': 0.84; 'populous': 0.84;
'speaking,': 0.84; 'subject:days': 0.84; 'subject:only': 0.84;
'migrates': 0.91; 'clock': 0.93; 'land': 0.93
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=Ix76VmjTl0y9yFzH+5sB3pju8yYL+ZU8esBNW5EWQZQ=;
b=qu1aVoOVpePH+cJKZOxwFLh3edwlCVsRKEOEpc2HpCoDECX8K11LkSFo6EEPKoI8yR
bm/zSNiKlB+pqi6JdUeJSWofYLBrIiuWUu/4Sqohv45DqGShZvmJz0BYF8O8RN8SsNVz
voSIVbyfFE53PYZK0HK6Tpyd//a5h5QhCTYhUXAzYRRC5Hl1fuKb2qYxx4ZZmhmZI69C
QhhxYU6wNVxtxLUdZ+fpRFEsFThlEs0lH3lyjqDihIBykp2Tr2yZ7NdZHk7Ax+OB2/6v
xQzX9bzj9kh/rSrU5SQRj4UIK2gVErrYKnPTr4rhl7vdSXO8FwMl/BXko/U/FeeAC6wt
Uf3g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to;
bh=Ix76VmjTl0y9yFzH+5sB3pju8yYL+ZU8esBNW5EWQZQ=;
b=B3vwWqcT+yN5vG69W9gmVBpVFKeBWlN4JoSrT0Yk8yPJOC19F273WEPoB0tzAL5wGt
xbd66uo1mGkHCym/+4NV0EHn1CaTCvnVcVJ50Ag46yzxcH+kajmRpgTEN08a0Uh13pAm
0oN05wtOS+PVslaX3Wg8yfhNyIcxtM5m7pCJBUOqpDIwqET9oItkasrurgwNXaYoXxbk
OBtaqfsg/zyI3+Jx75fGMm0XhLTcjbIkqN/FhtDmYJeigr9cQ0EIPUyYypYog+yLek+m
Hzd5MHaXQ8zeQ3iPA0b//QruG5gCwDAYsRAL9QtITvIbP5t8LxQH3C9ATT3rfYTxLMLU
RN5Q==
X-Gm-Message-State: AOAM5316crD0C66pEAjUhHBgKxiqOuLcrt0IqB0kd+RNdmYjyGdVFKGV
D4I7Li7igu4C4FoD6H0727nz0OI9O3026xK/I1KgnAdK
X-Google-Smtp-Source: ABdhPJxWZx14Pc33VX/NLGEwlY6J26by8ZYBGXxc0EOJf4tDSWz5Y2zoJsgtYgQ5BOmcR/QDTSO+7DVGGvAD7FboOqg=
X-Received: by 2002:a5d:64ed:0:b0:20a:7d81:860d with SMTP id
g13-20020a5d64ed000000b0020a7d81860dmr3585798wri.104.1650149627488; Sat, 16
Apr 2022 15:53:47 -0700 (PDT)
In-Reply-To: <rtfm5hlf446gq0m1o67htu0v5i09r3532t@4ax.com>
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: <CAPTjJmqoUnmMp-8sm2REy8yPWw2FzYVU064-RDFO1AdEGgoX0g@mail.gmail.com>
X-Mailman-Original-References: <mailman.87.1649948491.20749.python-list@python.org>
<slrnt5gf1l.41c.jon+usenet@raven.unequivocal.eu>
<20220416084411.kkfjtz2bjl5wqo5o@hjp.at>
<mailman.123.1650098653.20749.python-list@python.org>
<slrnt5li7k.41c.jon+usenet@raven.unequivocal.eu>
<slrnt5lk8c.41c.jon+usenet@raven.unequivocal.eu>
<20220416160028.tmedahn64gdpzsov@hjp.at>
<mailman.127.1650124831.20749.python-list@python.org>
<slrnt5ma4a.41c.jon+usenet@raven.unequivocal.eu>
<rtfm5hlf446gq0m1o67htu0v5i09r3532t@4ax.com>
 by: Chris Angelico - Sat, 16 Apr 2022 22:53 UTC

On Sun, 17 Apr 2022 at 08:37, Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:
> And proposals to make
> DST permanent year round -- so "noon" (1200hrs) is not "noon" (sun at
> zenith) pretty much anywhere.
>

Noon isn't precisely zenith anyway, for several reasons:

1) Time zones synchronize their clocks on the mean noon at some
location. Usually that's approximately close to the most populous part
of the region, but not always - for instance, all of China is on one
timezone, despite spanning 4-5 hours' worth of solar noon.

2) Solar noon migrates around a bit during the year. I don't remember
the exact figures, but if you want to read a sundial with any
precision, you need to take a date-based adjustment.

3) Solar days aren't all 24 hours long anyway.

The clock and calendar should *roughly* correspond to the sun, in that
broadly speaking, 2AM will be in darkness and 2PM will be in sunlight,
and the solstices will land in June and December. But down to the
minute, it's much more useful to synchronize on atomic time than
astronomical.

ChrisA

Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?

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

 copy mid

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

 copy link   Newsgroups: comp.lang.python
Path: i2pn2.org!i2pn.org!news.swapon.de!fu-berlin.de!uni-berlin.de!not-for-mail
From: hjp-pyt...@hjp.at (Peter J. Holzer)
Newsgroups: comp.lang.python
Subject: Re: Why does datetime.timedelta only have the attributes 'days' and
'seconds'?
Date: Sun, 17 Apr 2022 09:26:51 +0200
Lines: 125
Message-ID: <mailman.147.1650180414.20749.python-list@python.org>
References: <0b6be8d41b466ddd60787ddaecd26d063e961fc0.camel@anode.ca>
<mailman.87.1649948491.20749.python-list@python.org>
<slrnt5gf1l.41c.jon+usenet@raven.unequivocal.eu>
<20220416084411.kkfjtz2bjl5wqo5o@hjp.at>
<mailman.123.1650098653.20749.python-list@python.org>
<slrnt5li7k.41c.jon+usenet@raven.unequivocal.eu>
<slrnt5lk8c.41c.jon+usenet@raven.unequivocal.eu>
<20220416160028.tmedahn64gdpzsov@hjp.at>
<mailman.127.1650124831.20749.python-list@python.org>
<slrnt5ma4a.41c.jon+usenet@raven.unequivocal.eu>
<20220417072651.6tcttzdx4mhptv2v@hjp.at>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
protocol="application/pgp-signature"; boundary="v6ja5zvqyl3g6iqm"
X-Trace: news.uni-berlin.de w/EdnP1NqpzOaJuHwD5+hAUdTsqmR9HovRb49O/WrUoA==
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; 'looks': 0.02; 'this:':
0.03; 'knows': 0.04; '31,': 0.05; 'absolute': 0.05; 'content-
type:multipart/signed': 0.05; 'programmer': 0.07; 'string': 0.07;
'subject:Why': 0.07; 'utc': 0.07; 'adapt': 0.09; 'content-
type:application/pgp-signature': 0.09; 'converting': 0.09;
'datetime': 0.09; 'filename:fname piece:asc': 0.09;
'filename:fname piece:signature': 0.09;
'filename:fname:signature.asc': 0.09; 'forced': 0.09; 'like,':
0.09; 'meant': 0.09; "shouldn't": 0.09; 'skip:z 20': 0.09;
'though.': 0.09; 'import': 0.15; 'problem.': 0.15; 'that.': 0.15;
'"creative': 0.16; '__/': 0.16; 'bugs': 0.16; 'calculations':
0.16; 'challenge!"': 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; 'indeed':
0.16; "isn't.": 0.16; 'reality.': 0.16; 'semantics': 0.16;
'stross,': 0.16; 'subject:does': 0.16; 'subject:seconds': 0.16;
'timezone': 0.16; 'turns': 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; 'wrote:': 0.16; 'python': 0.16; "aren't":
0.19; 'it?': 0.19; 'to:addr:python-list': 0.20; 'i.e.': 0.22;
'returns': 0.22; 'anything': 0.25; 'python,': 0.25; 'saying':
0.25; 'library': 0.26; 'object': 0.26; 'local': 0.27; '>>>': 0.28;
'sense': 0.28; 'wrong': 0.28; 'looked': 0.31; 'module': 0.31;
'think': 0.32; "doesn't": 0.32; '(as': 0.32; 'guess': 0.32;
'programmers': 0.32; 'python-list': 0.32; 'but': 0.32; "i'm":
0.33; 'able': 0.34; "didn't": 0.34; 'header:In-Reply-To:1': 0.34;
'"the': 0.35; 'subject:skip:d 10': 0.35; 'really': 0.37; "it's":
0.37; 'way': 0.38; 'put': 0.38; 'use': 0.39; 'to.': 0.39; 'still':
0.40; 'appears': 0.40; 'seconds': 0.40; 'something': 0.40; 'want':
0.40; 'should': 0.40; '10,': 0.61; 'here.': 0.61; 'received:212':
0.62; 'ever': 0.63; 'hours': 0.63; 'definition': 0.64; 'needs.':
0.64; 'your': 0.64; 'top': 0.65; 'received:userid': 0.66; 'day':
0.66; 'decided': 0.67; 'skip:t 30': 0.67; 'time,': 0.67; 'that,':
0.67; 'url-ip:212/8': 0.69; 'european': 0.70; 'ignore': 0.71;
'subject:have': 0.75; 'guarantee': 0.76; 'implemented': 0.76;
'zone': 0.76; 'period': 0.81; 'conservative': 0.84; 'jon': 0.84;
'leap': 0.84; 'received:at': 0.84; 'skip:z 40': 0.84;
'subject:days': 0.84; 'subject:only': 0.84; 'want.': 0.84;
'badly': 0.91; 'somebody': 0.91; 'zone.': 0.91; 'central': 0.95
Mail-Followup-To: python-list@python.org
Content-Disposition: inline
In-Reply-To: <slrnt5ma4a.41c.jon+usenet@raven.unequivocal.eu>
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: <20220417072651.6tcttzdx4mhptv2v@hjp.at>
X-Mailman-Original-References: <0b6be8d41b466ddd60787ddaecd26d063e961fc0.camel@anode.ca>
<mailman.87.1649948491.20749.python-list@python.org>
<slrnt5gf1l.41c.jon+usenet@raven.unequivocal.eu>
<20220416084411.kkfjtz2bjl5wqo5o@hjp.at>
<mailman.123.1650098653.20749.python-list@python.org>
<slrnt5li7k.41c.jon+usenet@raven.unequivocal.eu>
<slrnt5lk8c.41c.jon+usenet@raven.unequivocal.eu>
<20220416160028.tmedahn64gdpzsov@hjp.at>
<mailman.127.1650124831.20749.python-list@python.org>
<slrnt5ma4a.41c.jon+usenet@raven.unequivocal.eu>
 by: Peter J. Holzer - Sun, 17 Apr 2022 07:26 UTC
Attachments: signature.asc (application/pgp-signature)

On 2022-04-16 20:35:22 -0000, Jon Ribbens via Python-list wrote:
> On 2022-04-16, Peter J. Holzer <hjp-python@hjp.at> wrote:
> > On 2022-04-16 14:22:04 -0000, Jon Ribbens via Python-list wrote:
> >> ... although now having looked into the new 'zoneinfo' module slightly,
> >> it really should have a giant red flashing notice at the top of it
> >> saying "BEWARE, TIMEZONES IN PYTHON ARE UTTERLY BROKEN, NEVER USE THEM".
> >>
> >> Suppose we do this:
> >>
> >> >>> import datetime, zoneinfo
> >> >>> LOS_ANGELES = zoneinfo.ZoneInfo('America/Los_Angeles')
> >> >>> UTC = zoneinfo.ZoneInfo('UTC')
> >> >>> d = datetime.datetime(2020, 10, 31, 12, tzinfo=LOS_ANGELES)
> >> >>> print(d)
> >> 2020-10-31 12:00:00-07:00
> >> >>> d1 = d + datetime.timedelta(days=1)
> >> >>> print(d1)
> >> 2020-11-01 12:00:00-08:00
> >>
> >> d1 is *wrong*.
> >
> > No, this is correct. That's the result you want.
>
> I can categorically guarantee you it is not. But let's put it a
> different way, if you like, if I want to add 24 hours, i.e. 86,400
> seconds (or indeed any other fixed time period), to a timezone-aware
> datetime in Python, how do I do it?

What you *should* be able to do is use datetime.timedelta(hours=24).

Unfortunately, you can't, because somebody decided to add a
normalization rule to timedelta which turns this into timedelta(days=1,
hours=0).

> It would appear that, without converting to UTC before doing the
> calculation, you can't.

When doing calculations of this kind I frankly prefer converting to
"seconds since the epoch" and doing simple arithmetic. (Yes, leap
seconds, I know .. I just ignore those)

> > So why didn't this work for me (I also used Python 3.9)? My guess is
> > that astimezone() doesn't pick the correct time zone.
>
> astimezone() doesn't pick a time zone at all. It works out the current
> local offset from UTC.

The timezone object it returns also includes a timezone string ("CET" in
my example). So it's not *just* the offset. The result is misleading,
though. You get something which looks like it's a timezone object for
Central European Time, but isn't.

> It doesn't know anything about when or if that
> offset ever changes.

astimezone() doesn't have to. It just has to pick the correct timezone
object. That object then knows about offset changes.

> >> timedelta(days=1) is 24 hours (as you can check by
> >> calling timedelta(days=1).total_seconds() ),
> >
> > It shouldn't be. 1 Day is not 24 hours in the real world.
>
> Nevertheless, timedelta is a fixed time period so that is the only
> definition possible.

Yeah, you keep repeating that. I think we are talking at cross-purposes
here. You are talking about how timedelta is implemented while I'm
talking what semantics it *should* have.

> >> It appears that with Python it's not so much a guideline as an
> >> absolute concrete rule, and not because programmers will introduce
> >> bugs, but because you need to avoid bugs in the standard library!
> >
> > As a programmer you must always adapt to the problem. Saying "I must do
> > it the wrong way because my library is buggy" is just lazy.
>
> I didn't say any of that. I said you must do it the conservative way,
> and it's not "my library" that's buggy, it's the language's built-in
> *standard library* that's buggy.

With "your library" I meant "the library you have" not "the library you
wrote". And while having a buggy (or just badly designed) standard
library is especially annoying, you still aren't forced to use it if if
doesn't fit your needs.

hp

--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"

Attachments: signature.asc (application/pgp-signature)
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?

<87ee1t49ae.fsf@hornfels.zedat.fu-berlin.de>

 copy mid

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

 copy link   Newsgroups: comp.lang.python
Path: i2pn2.org!i2pn.org!news.swapon.de!fu-berlin.de!uni-berlin.de!not-for-mail
From: loris.be...@fu-berlin.de (Loris Bennett)
Newsgroups: comp.lang.python
Subject: Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
Date: Tue, 19 Apr 2022 13:11:53 +0200
Organization: Freie Universitaet Berlin
Lines: 114
Message-ID: <87ee1t49ae.fsf@hornfels.zedat.fu-berlin.de>
References: <0b6be8d41b466ddd60787ddaecd26d063e961fc0.camel@anode.ca>
<mailman.87.1649948491.20749.python-list@python.org>
<slrnt5gf1l.41c.jon+usenet@raven.unequivocal.eu>
<20220416084411.kkfjtz2bjl5wqo5o@hjp.at>
<mailman.123.1650098653.20749.python-list@python.org>
<slrnt5li7k.41c.jon+usenet@raven.unequivocal.eu>
<slrnt5lk8c.41c.jon+usenet@raven.unequivocal.eu>
<20220416160028.tmedahn64gdpzsov@hjp.at>
<mailman.127.1650124831.20749.python-list@python.org>
<slrnt5ma4a.41c.jon+usenet@raven.unequivocal.eu>
<20220417072651.6tcttzdx4mhptv2v@hjp.at>
<mailman.147.1650180414.20749.python-list@python.org>
Mime-Version: 1.0
Content-Type: text/plain
X-Trace: news.uni-berlin.de veoCRzFG1a6iZiazmatjbQd/8AQKUEI0CilhjVOYlqQYrt
Cancel-Lock: sha1:HUZ+JwsCwGbnmotjx0gjlfHUPMs=
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
 by: Loris Bennett - Tue, 19 Apr 2022 11:11 UTC

"Peter J. Holzer" <hjp-python@hjp.at> writes:

> On 2022-04-16 20:35:22 -0000, Jon Ribbens via Python-list wrote:
>> On 2022-04-16, Peter J. Holzer <hjp-python@hjp.at> wrote:
>> > On 2022-04-16 14:22:04 -0000, Jon Ribbens via Python-list wrote:
>> >> ... although now having looked into the new 'zoneinfo' module slightly,
>> >> it really should have a giant red flashing notice at the top of it
>> >> saying "BEWARE, TIMEZONES IN PYTHON ARE UTTERLY BROKEN, NEVER USE THEM".
>> >>
>> >> Suppose we do this:
>> >>
>> >> >>> import datetime, zoneinfo
>> >> >>> LOS_ANGELES = zoneinfo.ZoneInfo('America/Los_Angeles')
>> >> >>> UTC = zoneinfo.ZoneInfo('UTC')
>> >> >>> d = datetime.datetime(2020, 10, 31, 12, tzinfo=LOS_ANGELES)
>> >> >>> print(d)
>> >> 2020-10-31 12:00:00-07:00
>> >> >>> d1 = d + datetime.timedelta(days=1)
>> >> >>> print(d1)
>> >> 2020-11-01 12:00:00-08:00
>> >>
>> >> d1 is *wrong*.
>> >
>> > No, this is correct. That's the result you want.
>>
>> I can categorically guarantee you it is not. But let's put it a
>> different way, if you like, if I want to add 24 hours, i.e. 86,400
>> seconds (or indeed any other fixed time period), to a timezone-aware
>> datetime in Python, how do I do it?
>
> What you *should* be able to do is use datetime.timedelta(hours=24).
>
> Unfortunately, you can't, because somebody decided to add a
> normalization rule to timedelta which turns this into timedelta(days=1,
> hours=0).
>
>> It would appear that, without converting to UTC before doing the
>> calculation, you can't.
>
> When doing calculations of this kind I frankly prefer converting to
> "seconds since the epoch" and doing simple arithmetic. (Yes, leap
> seconds, I know .. I just ignore those)
>
>
>> > So why didn't this work for me (I also used Python 3.9)? My guess is
>> > that astimezone() doesn't pick the correct time zone.
>>
>> astimezone() doesn't pick a time zone at all. It works out the current
>> local offset from UTC.
>
> The timezone object it returns also includes a timezone string ("CET" in
> my example). So it's not *just* the offset. The result is misleading,
> though. You get something which looks like it's a timezone object for
> Central European Time, but isn't.
>
>> It doesn't know anything about when or if that
>> offset ever changes.
>
> astimezone() doesn't have to. It just has to pick the correct timezone
> object. That object then knows about offset changes.
>
>
>> >> timedelta(days=1) is 24 hours (as you can check by
>> >> calling timedelta(days=1).total_seconds() ),
>> >
>> > It shouldn't be. 1 Day is not 24 hours in the real world.
>>
>> Nevertheless, timedelta is a fixed time period so that is the only
>> definition possible.
>
> Yeah, you keep repeating that. I think we are talking at cross-purposes
> here. You are talking about how timedelta is implemented while I'm
> talking what semantics it *should* have.
>
>
>> >> It appears that with Python it's not so much a guideline as an
>> >> absolute concrete rule, and not because programmers will introduce
>> >> bugs, but because you need to avoid bugs in the standard library!
>> >
>> > As a programmer you must always adapt to the problem. Saying "I must do
>> > it the wrong way because my library is buggy" is just lazy.
>>
>> I didn't say any of that. I said you must do it the conservative way,
>> and it's not "my library" that's buggy, it's the language's built-in
>> *standard library* that's buggy.
>
> With "your library" I meant "the library you have" not "the library you
> wrote". And while having a buggy (or just badly designed) standard
> library is especially annoying, you still aren't forced to use it if if
> doesn't fit your needs.
>
> hp

I now realise that timedelta is not really what I need. I am interested
solely in pure periods, i.e. numbers of seconds, that I can convert back
and forth from a format such as

11-22::44:55

(These are the lengths of time a job has run on an HPC system - leap
seconds and time zones are of no relevance).

It is obviously fairly easy to rustle up something to do this, but I am
surprised that this is not baked into Python (such a class also seems to
be missing from R). I would have thought that periods crop up all over
the place and therefore formatting as strings and parsing of string
would be supported natively by most modern languages. Apparently not.

Cheers,

Loris

--
This signature is currently under construction.

Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?

<slrnt5t99q.7j14.jon+usenet@raven.unequivocal.eu>

 copy mid

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

 copy link   Newsgroups: comp.lang.python
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: jon+use...@unequivocal.eu (Jon Ribbens)
Newsgroups: comp.lang.python
Subject: Re: Why does datetime.timedelta only have the attributes 'days' and
'seconds'?
Date: Tue, 19 Apr 2022 12:04:10 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 29
Message-ID: <slrnt5t99q.7j14.jon+usenet@raven.unequivocal.eu>
References: <0b6be8d41b466ddd60787ddaecd26d063e961fc0.camel@anode.ca>
<mailman.87.1649948491.20749.python-list@python.org>
<slrnt5gf1l.41c.jon+usenet@raven.unequivocal.eu>
<20220416084411.kkfjtz2bjl5wqo5o@hjp.at>
<mailman.123.1650098653.20749.python-list@python.org>
<slrnt5li7k.41c.jon+usenet@raven.unequivocal.eu>
<slrnt5lk8c.41c.jon+usenet@raven.unequivocal.eu>
<20220416160028.tmedahn64gdpzsov@hjp.at>
<mailman.127.1650124831.20749.python-list@python.org>
<slrnt5ma4a.41c.jon+usenet@raven.unequivocal.eu>
<20220417072651.6tcttzdx4mhptv2v@hjp.at>
<mailman.147.1650180414.20749.python-list@python.org>
<87ee1t49ae.fsf@hornfels.zedat.fu-berlin.de>
Injection-Date: Tue, 19 Apr 2022 12:04:10 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="ffc18bdace02b751447b1386f7d0c1db";
logging-data="31616"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19pjjBqPVtK9F6HEI8xya8niSLfrIO1IEs="
User-Agent: slrn/1.0.3 (Linux)
Cancel-Lock: sha1:6WC4pMsw/d1T9jqrpicJY/J5hts=
 by: Jon Ribbens - Tue, 19 Apr 2022 12:04 UTC

On 2022-04-19, Loris Bennett <loris.bennett@fu-berlin.de> wrote:
> I now realise that timedelta is not really what I need. I am interested
> solely in pure periods, i.e. numbers of seconds,

That's exactly what timedelta is.

> that I can convert back and forth from a format such as
>
> 11-22::44:55

I don't recognise that format and can't work out what it means.
It should be trivial to write functions to parse whatever format
you wanted and convert between it and timedelta objects though.

> It is obviously fairly easy to rustle up something to do this, but I am
> surprised that this is not baked into Python (such a class also seems to
> be missing from R).

I would be very surprised if any language supported the arbitrary format
above you happen to be interested in!

> I would have thought that periods crop up all over
> the place and therefore formatting as strings and parsing of string
> would be supported natively by most modern languages. Apparently not.

I think most languages think that a simple number suffices to represent
a fixed time period (commonly seconds or milliseconds). And if you want
more dynamic intervals (e.g. x months y days) then there is insufficient
consensus as to what that actually means.

Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?

<8735i944im.fsf@hornfels.zedat.fu-berlin.de>

 copy mid

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

 copy link   Newsgroups: comp.lang.python
Path: i2pn2.org!i2pn.org!news.swapon.de!fu-berlin.de!uni-berlin.de!not-for-mail
From: loris.be...@fu-berlin.de (Loris Bennett)
Newsgroups: comp.lang.python
Subject: Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
Date: Tue, 19 Apr 2022 14:54:57 +0200
Organization: Freie Universitaet Berlin
Lines: 49
Message-ID: <8735i944im.fsf@hornfels.zedat.fu-berlin.de>
References: <0b6be8d41b466ddd60787ddaecd26d063e961fc0.camel@anode.ca>
<mailman.87.1649948491.20749.python-list@python.org>
<slrnt5gf1l.41c.jon+usenet@raven.unequivocal.eu>
<20220416084411.kkfjtz2bjl5wqo5o@hjp.at>
<mailman.123.1650098653.20749.python-list@python.org>
<slrnt5li7k.41c.jon+usenet@raven.unequivocal.eu>
<slrnt5lk8c.41c.jon+usenet@raven.unequivocal.eu>
<20220416160028.tmedahn64gdpzsov@hjp.at>
<mailman.127.1650124831.20749.python-list@python.org>
<slrnt5ma4a.41c.jon+usenet@raven.unequivocal.eu>
<20220417072651.6tcttzdx4mhptv2v@hjp.at>
<mailman.147.1650180414.20749.python-list@python.org>
<87ee1t49ae.fsf@hornfels.zedat.fu-berlin.de>
<slrnt5t99q.7j14.jon+usenet@raven.unequivocal.eu>
Mime-Version: 1.0
Content-Type: text/plain
X-Trace: news.uni-berlin.de oe44oyL19Db+04MpPOtF6QN7V1FDY3ZPOiX1C78nbVNHhg
Cancel-Lock: sha1:Czxy8SpskNtvjQkb7uqMq8ILlaU=
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
 by: Loris Bennett - Tue, 19 Apr 2022 12:54 UTC

Jon Ribbens <jon+usenet@unequivocal.eu> writes:

> On 2022-04-19, Loris Bennett <loris.bennett@fu-berlin.de> wrote:
>> I now realise that timedelta is not really what I need. I am interested
>> solely in pure periods, i.e. numbers of seconds,
>
> That's exactly what timedelta is.
>
>> that I can convert back and forth from a format such as
>>
>> 11-22::44:55
>
> I don't recognise that format and can't work out what it means.
> It should be trivial to write functions to parse whatever format
> you wanted and convert between it and timedelta objects though.

days-hours:minutes:seconds

>> It is obviously fairly easy to rustle up something to do this, but I am
>> surprised that this is not baked into Python (such a class also seems to
>> be missing from R).
>
> I would be very surprised if any language supported the arbitrary format
> above you happen to be interested in!

But most languages support fairly arbitrary formatting of timedate-style
objects. It doesn't seem unreasonable to me that such formatting might
be available for simple periods.

>> I would have thought that periods crop up all over
>> the place and therefore formatting as strings and parsing of string
>> would be supported natively by most modern languages. Apparently not.
>
> I think most languages think that a simple number suffices to represent
> a fixed time period (commonly seconds or milliseconds). And if you want
> more dynamic intervals (e.g. x months y days) then there is insufficient
> consensus as to what that actually means.

Maybe. It just seems to me that once you get up to more than a few
hundred seconds, the ability to convert and from a more readable format
becomes very useful. The length of a month may be unclear, but the
definitions for year, week, day, hours, and minute are all trivial.

Cheers,

Loris

--
This signature is currently under construction.

Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?

<slrnt5tdf3.7j14.jon+usenet@raven.unequivocal.eu>

 copy mid

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

 copy link   Newsgroups: comp.lang.python
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: jon+use...@unequivocal.eu (Jon Ribbens)
Newsgroups: comp.lang.python
Subject: Re: Why does datetime.timedelta only have the attributes 'days' and
'seconds'?
Date: Tue, 19 Apr 2022 13:15:15 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 54
Message-ID: <slrnt5tdf3.7j14.jon+usenet@raven.unequivocal.eu>
References: <0b6be8d41b466ddd60787ddaecd26d063e961fc0.camel@anode.ca>
<mailman.87.1649948491.20749.python-list@python.org>
<slrnt5gf1l.41c.jon+usenet@raven.unequivocal.eu>
<20220416084411.kkfjtz2bjl5wqo5o@hjp.at>
<mailman.123.1650098653.20749.python-list@python.org>
<slrnt5li7k.41c.jon+usenet@raven.unequivocal.eu>
<slrnt5lk8c.41c.jon+usenet@raven.unequivocal.eu>
<20220416160028.tmedahn64gdpzsov@hjp.at>
<mailman.127.1650124831.20749.python-list@python.org>
<slrnt5ma4a.41c.jon+usenet@raven.unequivocal.eu>
<20220417072651.6tcttzdx4mhptv2v@hjp.at>
<mailman.147.1650180414.20749.python-list@python.org>
<87ee1t49ae.fsf@hornfels.zedat.fu-berlin.de>
<slrnt5t99q.7j14.jon+usenet@raven.unequivocal.eu>
<8735i944im.fsf@hornfels.zedat.fu-berlin.de>
Injection-Date: Tue, 19 Apr 2022 13:15:15 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="ffc18bdace02b751447b1386f7d0c1db";
logging-data="13757"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX197KrwswaE8d4YpWe9qfDlljZ76rMXaunQ="
User-Agent: slrn/1.0.3 (Linux)
Cancel-Lock: sha1:3vYz/H3b2o4FwOO8awjfrQxg3tU=
 by: Jon Ribbens - Tue, 19 Apr 2022 13:15 UTC

On 2022-04-19, Loris Bennett <loris.bennett@fu-berlin.de> wrote:
> Jon Ribbens <jon+usenet@unequivocal.eu> writes:
>> On 2022-04-19, Loris Bennett <loris.bennett@fu-berlin.de> wrote:
>>> I now realise that timedelta is not really what I need. I am interested
>>> solely in pure periods, i.e. numbers of seconds,
>>
>> That's exactly what timedelta is.
>>
>>> that I can convert back and forth from a format such as
>>>
>>> 11-22::44:55
>>
>> I don't recognise that format and can't work out what it means.
>> It should be trivial to write functions to parse whatever format
>> you wanted and convert between it and timedelta objects though.
>
> days-hours:minutes:seconds

If by 'days' it means '86,400 seconds' then that's very easily
convertible to and from timedelta.

>> I would be very surprised if any language supported the arbitrary format
>> above you happen to be interested in!
>
> But most languages support fairly arbitrary formatting of timedate-style
> objects. It doesn't seem unreasonable to me that such formatting might
> be available for simple periods.
>
>>> I would have thought that periods crop up all over
>>> the place and therefore formatting as strings and parsing of string
>>> would be supported natively by most modern languages. Apparently not.
>>
>> I think most languages think that a simple number suffices to represent
>> a fixed time period (commonly seconds or milliseconds). And if you want
>> more dynamic intervals (e.g. x months y days) then there is insufficient
>> consensus as to what that actually means.
>
> Maybe. It just seems to me that once you get up to more than a few
> hundred seconds, the ability to convert and from a more readable format
> becomes very useful. The length of a month may be unclear, but the
> definitions for year, week, day, hours, and minute are all trivial.

Eh? The definitions for "year, week, day" are not in the slightest bit
trivial (unless you define 'day' as '86,400 seconds', in which case
'year' is still not remotely trivial).

I think the issue is simply lack of consensus. Even though ISO 8601,
which is extremely common (possibly even ubiquitous, for anything
modern) for the format of date/times, also defines a format for
durations (e.g. 'P4Y3M' for '4 years 3 months'), I don't think
I have ever seen it used in practice - not least because apparently
it doesn't define what it actually means. So there isn't one simple
standard agreed by everyone that is an obvious candidate for inclusion
in language standard libraries.

Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?

<87r15t2nci.fsf@hornfels.zedat.fu-berlin.de>

 copy mid

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

 copy link   Newsgroups: comp.lang.python
Path: i2pn2.org!i2pn.org!news.swapon.de!fu-berlin.de!uni-berlin.de!not-for-mail
From: loris.be...@fu-berlin.de (Loris Bennett)
Newsgroups: comp.lang.python
Subject: Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
Date: Tue, 19 Apr 2022 15:51:09 +0200
Organization: Freie Universitaet Berlin
Lines: 91
Message-ID: <87r15t2nci.fsf@hornfels.zedat.fu-berlin.de>
References: <0b6be8d41b466ddd60787ddaecd26d063e961fc0.camel@anode.ca>
<mailman.87.1649948491.20749.python-list@python.org>
<slrnt5gf1l.41c.jon+usenet@raven.unequivocal.eu>
<20220416084411.kkfjtz2bjl5wqo5o@hjp.at>
<mailman.123.1650098653.20749.python-list@python.org>
<slrnt5li7k.41c.jon+usenet@raven.unequivocal.eu>
<slrnt5lk8c.41c.jon+usenet@raven.unequivocal.eu>
<20220416160028.tmedahn64gdpzsov@hjp.at>
<mailman.127.1650124831.20749.python-list@python.org>
<slrnt5ma4a.41c.jon+usenet@raven.unequivocal.eu>
<20220417072651.6tcttzdx4mhptv2v@hjp.at>
<mailman.147.1650180414.20749.python-list@python.org>
<87ee1t49ae.fsf@hornfels.zedat.fu-berlin.de>
<slrnt5t99q.7j14.jon+usenet@raven.unequivocal.eu>
<8735i944im.fsf@hornfels.zedat.fu-berlin.de>
<slrnt5tdf3.7j14.jon+usenet@raven.unequivocal.eu>
Mime-Version: 1.0
Content-Type: text/plain
X-Trace: news.uni-berlin.de 7yj4m0JuVYPZqYKDtBlOkQqAjPZQeAQCI5bpGdUKuT5PjC
Cancel-Lock: sha1:SavbBPvQPK/vGN2r/wGk4joEzwA=
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
 by: Loris Bennett - Tue, 19 Apr 2022 13:51 UTC

Jon Ribbens <jon+usenet@unequivocal.eu> writes:

> On 2022-04-19, Loris Bennett <loris.bennett@fu-berlin.de> wrote:
>> Jon Ribbens <jon+usenet@unequivocal.eu> writes:
>>> On 2022-04-19, Loris Bennett <loris.bennett@fu-berlin.de> wrote:
>>>> I now realise that timedelta is not really what I need. I am interested
>>>> solely in pure periods, i.e. numbers of seconds,
>>>
>>> That's exactly what timedelta is.
>>>
>>>> that I can convert back and forth from a format such as
>>>>
>>>> 11-22::44:55
>>>
>>> I don't recognise that format and can't work out what it means.
>>> It should be trivial to write functions to parse whatever format
>>> you wanted and convert between it and timedelta objects though.
>>
>> days-hours:minutes:seconds
>
> If by 'days' it means '86,400 seconds' then that's very easily
> convertible to and from timedelta.
>
>>> I would be very surprised if any language supported the arbitrary format
>>> above you happen to be interested in!
>>
>> But most languages support fairly arbitrary formatting of timedate-style
>> objects. It doesn't seem unreasonable to me that such formatting might
>> be available for simple periods.
>>
>>>> I would have thought that periods crop up all over
>>>> the place and therefore formatting as strings and parsing of string
>>>> would be supported natively by most modern languages. Apparently not.
>>>
>>> I think most languages think that a simple number suffices to represent
>>> a fixed time period (commonly seconds or milliseconds). And if you want
>>> more dynamic intervals (e.g. x months y days) then there is insufficient
>>> consensus as to what that actually means.
>>
>> Maybe. It just seems to me that once you get up to more than a few
>> hundred seconds, the ability to convert and from a more readable format
>> becomes very useful. The length of a month may be unclear, but the
>> definitions for year, week, day, hours, and minute are all trivial.
>
> Eh? The definitions for "year, week, day" are not in the slightest bit
> trivial (unless you define 'day' as '86,400 seconds', in which case
> 'year' is still not remotely trivial).

Yes, I do mean just the trivial definitions from

https://docs.python.org/3/library/datetime.html

i.e.

A millisecond is converted to 1000 microseconds.
A minute is converted to 60 seconds.
An hour is converted to 3600 seconds.
A week is converted to 7 days.

plus a 24-hour day and a 365-day year.

> I think the issue is simply lack of consensus. Even though ISO 8601,
> which is extremely common (possibly even ubiquitous, for anything
> modern) for the format of date/times, also defines a format for
> durations (e.g. 'P4Y3M' for '4 years 3 months'), I don't think
> I have ever seen it used in practice - not least because apparently
> it doesn't define what it actually means. So there isn't one simple
> standard agreed by everyone that is an obvious candidate for inclusion
> in language standard libraries.

If I am merely trying to represent part a very large number of seconds
as a number of years, 365 days per year does not seem that controversial
to me. Obviously there are issues if you expect all periods of an
integer number of years which start on a given date to all end on the
same date.

In my little niche, I just need a very simple period and am anyway not
bothered about years, since in my case the number of days is usually
capped at 14 and only in extremely exceptional circumstances could it
get up to anywhere near 100.

However, surely there are plenty of people measuring durations of a few
hours or less who don't want to have to deal with seconds all the time
(I am in fact also in this other group when I record my working hours).

Cheers,

Loris

--
This signature is currently under construction.

Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?

<slrnt5tg6c.7j14.jon+usenet@raven.unequivocal.eu>

 copy mid

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

 copy link   Newsgroups: comp.lang.python
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: jon+use...@unequivocal.eu (Jon Ribbens)
Newsgroups: comp.lang.python
Subject: Re: Why does datetime.timedelta only have the attributes 'days' and
'seconds'?
Date: Tue, 19 Apr 2022 14:01:48 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 19
Message-ID: <slrnt5tg6c.7j14.jon+usenet@raven.unequivocal.eu>
References: <0b6be8d41b466ddd60787ddaecd26d063e961fc0.camel@anode.ca>
<mailman.87.1649948491.20749.python-list@python.org>
<slrnt5gf1l.41c.jon+usenet@raven.unequivocal.eu>
<20220416084411.kkfjtz2bjl5wqo5o@hjp.at>
<mailman.123.1650098653.20749.python-list@python.org>
<slrnt5li7k.41c.jon+usenet@raven.unequivocal.eu>
<slrnt5lk8c.41c.jon+usenet@raven.unequivocal.eu>
<20220416160028.tmedahn64gdpzsov@hjp.at>
<mailman.127.1650124831.20749.python-list@python.org>
<slrnt5ma4a.41c.jon+usenet@raven.unequivocal.eu>
<20220417072651.6tcttzdx4mhptv2v@hjp.at>
<mailman.147.1650180414.20749.python-list@python.org>
<87ee1t49ae.fsf@hornfels.zedat.fu-berlin.de>
<slrnt5t99q.7j14.jon+usenet@raven.unequivocal.eu>
<8735i944im.fsf@hornfels.zedat.fu-berlin.de>
<slrnt5tdf3.7j14.jon+usenet@raven.unequivocal.eu>
<87r15t2nci.fsf@hornfels.zedat.fu-berlin.de>
Injection-Date: Tue, 19 Apr 2022 14:01:48 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="ffc18bdace02b751447b1386f7d0c1db";
logging-data="13757"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19Jy2WoJ0Wmd0Od4beCEWcg/Lm5SkxNkX0="
User-Agent: slrn/1.0.3 (Linux)
Cancel-Lock: sha1:OBzwUHgb+oElv8hTvnH0LwQ5hy4=
 by: Jon Ribbens - Tue, 19 Apr 2022 14:01 UTC

On 2022-04-19, Loris Bennett <loris.bennett@fu-berlin.de> wrote:
> If I am merely trying to represent part a very large number of seconds
> as a number of years, 365 days per year does not seem that controversial
> to me. Obviously there are issues if you expect all periods of an
> integer number of years which start on a given date to all end on the
> same date.
>
> In my little niche, I just need a very simple period and am anyway not
> bothered about years, since in my case the number of days is usually
> capped at 14 and only in extremely exceptional circumstances could it
> get up to anywhere near 100.
>
> However, surely there are plenty of people measuring durations of a few
> hours or less who don't want to have to deal with seconds all the time
> (I am in fact also in this other group when I record my working hours).

Well, that's my point. Everyone's all in their own slightly-different
little niches. There isn't one straightforward standard that makes all
or even most of them happy.

Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?

<87lew12m0q.fsf@hornfels.zedat.fu-berlin.de>

 copy mid

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

 copy link   Newsgroups: comp.lang.python
Path: i2pn2.org!i2pn.org!news.swapon.de!fu-berlin.de!uni-berlin.de!not-for-mail
From: loris.be...@fu-berlin.de (Loris Bennett)
Newsgroups: comp.lang.python
Subject: Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
Date: Tue, 19 Apr 2022 16:19:49 +0200
Organization: Freie Universitaet Berlin
Lines: 35
Message-ID: <87lew12m0q.fsf@hornfels.zedat.fu-berlin.de>
References: <0b6be8d41b466ddd60787ddaecd26d063e961fc0.camel@anode.ca>
<mailman.87.1649948491.20749.python-list@python.org>
<slrnt5gf1l.41c.jon+usenet@raven.unequivocal.eu>
<20220416084411.kkfjtz2bjl5wqo5o@hjp.at>
<mailman.123.1650098653.20749.python-list@python.org>
<slrnt5li7k.41c.jon+usenet@raven.unequivocal.eu>
<slrnt5lk8c.41c.jon+usenet@raven.unequivocal.eu>
<20220416160028.tmedahn64gdpzsov@hjp.at>
<mailman.127.1650124831.20749.python-list@python.org>
<slrnt5ma4a.41c.jon+usenet@raven.unequivocal.eu>
<20220417072651.6tcttzdx4mhptv2v@hjp.at>
<mailman.147.1650180414.20749.python-list@python.org>
<87ee1t49ae.fsf@hornfels.zedat.fu-berlin.de>
<slrnt5t99q.7j14.jon+usenet@raven.unequivocal.eu>
<8735i944im.fsf@hornfels.zedat.fu-berlin.de>
<slrnt5tdf3.7j14.jon+usenet@raven.unequivocal.eu>
<87r15t2nci.fsf@hornfels.zedat.fu-berlin.de>
<slrnt5tg6c.7j14.jon+usenet@raven.unequivocal.eu>
Mime-Version: 1.0
Content-Type: text/plain
X-Trace: news.uni-berlin.de QeYBFwPPte6GNoKgR/xY4wkHUoIAfUy4g+D9GmlLgKOe41
Cancel-Lock: sha1:u7vKCWoP74haehDZF36jQ9cO7mc=
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
 by: Loris Bennett - Tue, 19 Apr 2022 14:19 UTC

Jon Ribbens <jon+usenet@unequivocal.eu> writes:

> On 2022-04-19, Loris Bennett <loris.bennett@fu-berlin.de> wrote:
>> If I am merely trying to represent part a very large number of seconds
>> as a number of years, 365 days per year does not seem that controversial
>> to me. Obviously there are issues if you expect all periods of an
>> integer number of years which start on a given date to all end on the
>> same date.
>>
>> In my little niche, I just need a very simple period and am anyway not
>> bothered about years, since in my case the number of days is usually
>> capped at 14 and only in extremely exceptional circumstances could it
>> get up to anywhere near 100.
>>
>> However, surely there are plenty of people measuring durations of a few
>> hours or less who don't want to have to deal with seconds all the time
>> (I am in fact also in this other group when I record my working hours).
>
> Well, that's my point. Everyone's all in their own slightly-different
> little niches. There isn't one straightforward standard that makes all
> or even most of them happy.

I'm sure you're right. I just strikes me as a little odd that so much
effort has gone into datetime to make things work (almost) properly for
(almost) everyone, whereas timedelta has remained rather rudimentary, at
least in terms of formatting. It seems to me that periods on the order
of hours would have quite generic applications, but maybe that's just
the view from my niche.

Cheers,

Loris

--
This signature is currently under construction.

Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?

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

 copy mid

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

 copy link   Newsgroups: comp.lang.python
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!3.eu.feeder.erje.net!feeder.erje.net!fu-berlin.de!uni-berlin.de!not-for-mail
From: ros...@gmail.com (Chris Angelico)
Newsgroups: comp.lang.python
Subject: Re: Why does datetime.timedelta only have the attributes 'days' and
'seconds'?
Date: Wed, 20 Apr 2022 03:12:15 +1000
Lines: 63
Message-ID: <mailman.158.1650388517.20749.python-list@python.org>
References: <0b6be8d41b466ddd60787ddaecd26d063e961fc0.camel@anode.ca>
<mailman.87.1649948491.20749.python-list@python.org>
<slrnt5gf1l.41c.jon+usenet@raven.unequivocal.eu>
<20220416084411.kkfjtz2bjl5wqo5o@hjp.at>
<mailman.123.1650098653.20749.python-list@python.org>
<slrnt5li7k.41c.jon+usenet@raven.unequivocal.eu>
<slrnt5lk8c.41c.jon+usenet@raven.unequivocal.eu>
<20220416160028.tmedahn64gdpzsov@hjp.at>
<mailman.127.1650124831.20749.python-list@python.org>
<slrnt5ma4a.41c.jon+usenet@raven.unequivocal.eu>
<20220417072651.6tcttzdx4mhptv2v@hjp.at>
<mailman.147.1650180414.20749.python-list@python.org>
<87ee1t49ae.fsf@hornfels.zedat.fu-berlin.de>
<CAPTjJmrpOstbRtDXwYHh-Qrfhp8kj44ch9vn6z16HzJwbemrHQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
X-Trace: news.uni-berlin.de 2n7akAiFMJfHiL9fNScPMAjxD7Jj2ruu/CoCIsmzD5BQ==
Return-Path: <rosuav@gmail.com>
X-Original-To: python-list@python.org
Delivered-To: python-list@mail.python.org
Authentication-Results: mail.python.org; dkim=pass
reason="2048-bit key; unprotected key"
header.d=gmail.com header.i=@gmail.com header.b=SGjpq/vF;
dkim-adsp=pass; dkim-atps=neutral
X-Spam-Status: UNSURE 0.279
X-Spam-Level: **
X-Spam-Evidence: '*H*': 0.44; '*S*': 0.00; '2022': 0.05; 'class,':
0.05; 'mar': 0.07; 'subject:Why': 0.07; 'converting': 0.09;
'derived': 0.09; 'fair,': 0.09; 'it)': 0.09; '(b)': 0.16; '(eg':
0.16; '1918': 0.16; 'bennett': 0.16; 'chrisa': 0.16; 'date,':
0.16; 'equally': 0.16; 'from:addr:rosuav': 0.16; 'from:name:chris
angelico': 0.16; 'hours,': 0.16; 'iso': 0.16; "it'd": 0.16;
'noting': 0.16; 'saturday': 0.16; 'seconds.': 0.16; 'sole': 0.16;
'specify': 0.16; 'subject:does': 0.16; 'subject:seconds': 0.16;
'such,': 0.16; 'third,': 0.16; 'timezone': 0.16; 'wrote:': 0.16;
'feb': 0.17; 'probably': 0.17; 'figure': 0.19; 'to:addr:python-
list': 0.20; 'exception': 0.22; 'i.e.': 0.22; 'run': 0.23; "i'd":
0.24; 'listing': 0.26; 'local': 0.27; 'official': 0.32;
'minutes,': 0.32; 'modified': 0.32; 'point,': 0.32; 'requiring':
0.32; 'message-id:@mail.gmail.com': 0.32; 'but': 0.32; 'year,':
0.33; 'header:In-Reply-To:1': 0.34; 'received:google.com': 0.34;
'"the': 0.35; 'fine': 0.35; 'meaning': 0.35; 'subject:skip:d 10':
0.35; 'from:addr:gmail.com': 0.35; 'possibly': 0.36; 'people':
0.36; 'really': 0.37; "it's": 0.37; 'received:209.85': 0.37;
'way': 0.38; 'could': 0.38; 'received:209': 0.39; 'two': 0.39;
'changes': 0.39; 'enough': 0.39; 'otherwise': 0.39; 'handle':
0.39; 'use': 0.39; 'wed,': 0.39; 'calendar': 0.40; 'date.': 0.40;
'define': 0.40; 'seconds': 0.40; 'want': 0.40; 'including': 0.60;
'best': 0.61; 'introduction': 0.61; "there's": 0.61; '5th': 0.62;
'format': 0.62; 'ever': 0.63; 'between': 0.63; 'complete': 0.64;
'full': 0.64; '15th': 0.64; '20th': 0.64; 'times.': 0.64; 'your':
0.64; 'his': 0.65; 'time.': 0.66; 'numbers': 0.67; 'back': 0.67;
'time,': 0.67; 'that,': 0.67; 'operations': 0.68; 'interested':
0.68; '2009': 0.69; '2010': 0.69; 'days,': 0.69; 'etc,': 0.69;
'julian': 0.69; '2016': 0.70; '2nd': 0.70; 'affected': 0.70;
'essential': 0.70; 'care': 0.71; 'january': 0.71; 'longer': 0.71;
"you'll": 0.73; 'june': 0.73; 'easy': 0.74; 'subject:have': 0.75;
'civil': 0.76; 'need,': 0.76; 'period.': 0.76; 'potentially':
0.76; 'zone': 0.76; 'database': 0.80; 'period': 0.81; 'need.':
0.84; 'york': 0.84; 'adjusting': 0.84; 'adjustments': 0.84;
'calendar,': 0.84; 'converted': 0.84; 'iso,': 0.84; 'leap': 0.84;
'realise': 0.84; 'russia': 0.84; 'subject:days': 0.84;
'subject:only': 0.84; '23rd': 0.91; 'zone.': 0.91; '30th': 0.95
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=KVBioN4nkTK7e5uF0s9yJdiEoKa1UWWrBuxFdhGcFoQ=;
b=SGjpq/vFXToHVSVGRY+mqHeoWu4eBNKa4dgktfjiGz60K6MPz+Xl7PVMBKuj5OSudm
WTwaqIDf0JQHho5qR/m/1fTEOAV21klE1kutKITapk936aA5J+LNHKEQwHBB0IXwUQCG
FTeOEGzhzKzcHVwRxEIykGfHeWeT9RwuZHvv30hJ2yo38krUFc6QnaVwkfu2X8HhpPVj
Kr1tqiNS71yBi9Nq5RouczIYtULOySE+90sxAaI3m05iRyiT1vHXb21v7OdwSKtJcEpU
6Z2jKORMlfG5tmutc4QQlHS4qN1kL8elmBLACrMiUTepAjkTqbsZr52+cAI+fwz51WoW
gBAg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to;
bh=KVBioN4nkTK7e5uF0s9yJdiEoKa1UWWrBuxFdhGcFoQ=;
b=6XNB/Od/CFOuKK8oP2cN1eQeMqTtamM8nmiQ0GPW8bMcbiz0RaB+IAVE6us3mxH5m4
ch96pOSsVqf75iuRpHqk7jnu7B+dlDaJUF2wCbEEntesSYZECVNmlhpxDwoWUFn2NJh+
DJwa/jVsQa5Y7JA5NNJh4jm5xYCp8zD8mqYUbe3fHdPzm0hjOSt6XpVmEiGHB7aERCzN
efxSQrgbGW6HaSfQraU0/v8NQyj1yik6pg1dhud1UhDRY5HxVV77TQfTVv4+hq2DcSy7
0WiZzwohRT8yFN1RIEM/3ZpbwxR/qLt9afi0jagy4LVbxM82m3cvNnk/V7HwBZfV8WY6
7oxA==
X-Gm-Message-State: AOAM531tNAYtHTARs/xJLLHm6HVgZXNEqgmgC+WexnJcTqZmrtlRk5aC
aeztgxtSQk5+KaC0vZwWvGzHRbYJily5zcl3TZynsSTF
X-Google-Smtp-Source: ABdhPJzaqP0VnmiI0cciT7wvOsk4JjnixmuBA2tyYg4Fbj5m31GtDWCobBo5Wr/8EKsjWqLliSV6moXyDOjDaaSNkG8=
X-Received: by 2002:a5d:6da8:0:b0:20a:9377:c389 with SMTP id
u8-20020a5d6da8000000b0020a9377c389mr9104482wrs.495.1650388347255; Tue, 19
Apr 2022 10:12:27 -0700 (PDT)
In-Reply-To: <87ee1t49ae.fsf@hornfels.zedat.fu-berlin.de>
X-Mailman-Approved-At: Tue, 19 Apr 2022 13:15:16 -0400
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: <CAPTjJmrpOstbRtDXwYHh-Qrfhp8kj44ch9vn6z16HzJwbemrHQ@mail.gmail.com>
X-Mailman-Original-References: <0b6be8d41b466ddd60787ddaecd26d063e961fc0.camel@anode.ca>
<mailman.87.1649948491.20749.python-list@python.org>
<slrnt5gf1l.41c.jon+usenet@raven.unequivocal.eu>
<20220416084411.kkfjtz2bjl5wqo5o@hjp.at>
<mailman.123.1650098653.20749.python-list@python.org>
<slrnt5li7k.41c.jon+usenet@raven.unequivocal.eu>
<slrnt5lk8c.41c.jon+usenet@raven.unequivocal.eu>
<20220416160028.tmedahn64gdpzsov@hjp.at>
<mailman.127.1650124831.20749.python-list@python.org>
<slrnt5ma4a.41c.jon+usenet@raven.unequivocal.eu>
<20220417072651.6tcttzdx4mhptv2v@hjp.at>
<mailman.147.1650180414.20749.python-list@python.org>
<87ee1t49ae.fsf@hornfels.zedat.fu-berlin.de>
 by: Chris Angelico - Tue, 19 Apr 2022 17:12 UTC

On Wed, 20 Apr 2022 at 02:16, Loris Bennett <loris.bennett@fu-berlin.de> wrote:
> I now realise that timedelta is not really what I need. I am interested
> solely in pure periods, i.e. numbers of seconds, that I can convert back
> and forth from a format such as
>
> 11-22::44:55
>
> (These are the lengths of time a job has run on an HPC system - leap
> seconds and time zones are of no relevance).

Thing is, there's a huge difference between:

1) "Eleven days, twenty-two hours, forty-four minutes, and fifty-five seconds"
2) "The period between 2nd May 2009 at 6AM and 5th June 2010 at 9AM"
3) "The period between 20th Feb 2016 at 10PM in New York and 30th Mar
2016 at 1AM in New York"
3b) "The period between 23rd Jan 1918 and 15th Feb 1918 in Moscow"

The first one is an abstract distance of time, and could be considered
broadly equivalent to the difference between two TIA timestamps or two
Unix times. Or UTC, as long as you don't care about inaccuracy around
leap seconds.

The second is a specific time period without a time zone. If assumed
to be UTC, or on an abstract calendar, it can be converted to and from
the first form, but if it's assumed to be local time, then it's
underspecified. It's affected by leap years, so you have to specify
the full date.

The third, and possibly fourth, are affected by civil time. (3b is
also potentially affected by a calendar switch; for people in Russia
at the time, the 23rd of January was a Julian date and the 15th of
February was a Gregorian date, so they were closer together than on
either calendar consistently. But I'd be fine with ignoring that, and
requiring the use of the Gregorian (or ISO, which is derived from it)
calendar.) Civil time is modified by regular adjustments (mostly DST),
official changes to time zone (eg the introduction or abolition of
DST, or choosing to align one's timezone with a neighbour), adoption
of standard time (often adjusting by a few minutes and/or seconds to
align with an hour boundary), etc, etc, etc. The only way to handle
civil time is (a) with full timestamps including the year, and (b)
with a complete timezone database listing all conversions. At this
point, the time period no longer has any abstract meaning, and its
sole meaning is "the time between these instants"; as such, it's
probably best calculated by converting the timestamps to UTC,
converting to Unix time, and taking the difference in seconds.

With the first option, there's no real meaning to it until you figure
out what you can actually *do* with that time period.

I believe ISO 8601 timestamps are about the most general you'll ever
need, with the possible exception of "9pm to 10pm second Saturday of
every month, if His Sufficiency feels like meeting with you, otherwise
never". (Though, to be fair, you could probably represent that with a
simple "Never" and it'd be just as correct.)

It's worth noting that pure seconds can easily be used as timedeltas.
If you want your form to be convertible back and forth with a number
of seconds, it's easy enough to subtract two datetimes by their Unix
times. But before defining the class, it's essential to define what
you want to do with it. Not all operations are equally meaningful.

ChrisA

Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?

<54pt5h55ee3b81oct6j35put5na51lk56h@4ax.com>

 copy mid

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

 copy link   Newsgroups: comp.lang.python
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 19 Apr 2022 13:23:10 -0500
From: wlfr...@ix.netcom.com (Dennis Lee Bieber)
Newsgroups: comp.lang.python
Subject: Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
Date: Tue, 19 Apr 2022 14:23:11 -0400
Organization: IISS Elusive Unicorn
Message-ID: <54pt5h55ee3b81oct6j35put5na51lk56h@4ax.com>
References: <20220416160028.tmedahn64gdpzsov@hjp.at> <mailman.127.1650124831.20749.python-list@python.org> <slrnt5ma4a.41c.jon+usenet@raven.unequivocal.eu> <20220417072651.6tcttzdx4mhptv2v@hjp.at> <mailman.147.1650180414.20749.python-list@python.org> <87ee1t49ae.fsf@hornfels.zedat.fu-berlin.de> <slrnt5t99q.7j14.jon+usenet@raven.unequivocal.eu> <8735i944im.fsf@hornfels.zedat.fu-berlin.de> <slrnt5tdf3.7j14.jon+usenet@raven.unequivocal.eu> <87r15t2nci.fsf@hornfels.zedat.fu-berlin.de>
User-Agent: ForteAgent/8.00.32.1272
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Lines: 98
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-5vWCpBMXQFrf18Ld7vHWe/pImusEf4A8/9L/fjmHqxQOzMyLgVSFcQnm4lgRbygX39ELl+y8W8ETw7a!LMErVj4gtllaErP5z3w9HH5pscd4UuES0eVa4Wt77G9Reqey4eE2tCGrMCk1VT6GmCYfYrrR
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 5704
 by: Dennis Lee Bieber - Tue, 19 Apr 2022 18:23 UTC

On Tue, 19 Apr 2022 15:51:09 +0200, "Loris Bennett"
<loris.bennett@fu-berlin.de> declaimed the following:

>If I am merely trying to represent part a very large number of seconds
>as a number of years, 365 days per year does not seem that controversial

The Explanatory Supplement to the Astronomical Almanac (table 15.3)
defines the /day/ as 24hrs->1440mins->86400secs BUT defines the Julian
/year/ as 365.25 days.

It goes on to also give (for my copy -- length of year at 1990):
Tropical (equinox to equinox) 365.2421897 days *
Sidereal (fixed star to fixed star) 365.25636 days
Anomalistic (perihelion to perihelion) 365.25964 days
Eclipse (moon's node to moon's node) 346.26005
Gaussian (Kepler's law /a/=1) 365.25690
Julian 365.25

Length of the month (I interpret this as lunar month):
Synodic (new moon to new moon) 29.53059 days
Tropical (as with year) 27.32158
Sidereal (as with year) 27.32166
Anomalistic (perigee to perigee) 27.55455
Draconic (node to node) 27.21222

* I /think/ this is the year used for leap-day calculations, and why some
leap centuries are skipped as it is really less than a quarter day per
year, so eventually one gets to over-correcting by a day.

Of course, this book also has a footnote giving the speed of light as
1.80261750E12 Furlongs/Fortnight <G>

However, as soon you incorporate units that are not SI seconds you have
to differentiate between pure duration (based on SI seconds) and civil time
(which may jump when leap seconds are added/subtracted, time zones are
crossed, or daylight savings time goes into [or out of] effect).

For the most part, Python's datetime module seems to account for civil
time concepts, not monotonic durations.

The Ada standard separates "duration" (as a measure of elapsed time, in
fixed point seconds) from "time" (a private type in Ada.Calendar -- which
does NOT define hours/minutes... It has Year 1901..2399, Month 1..12, Day
1..31, Day_duration 0.0..86400.0). There are functions to create a Time
from components, split a Time into components, compare two times, add a
Duration to a Time, subtract a Duration from a Time, and subtract a Time
from a Time (getting a Duration). Oh, and a function to get Time from
system clock. Per the standard, the Time Zone used is implementation
defined (so one needs to read the implementation manual to find out what a
Time really notates). Of note:
"""
26.a/1
To be honest: {8652/0106} {AI95-00160-01} By "proper date" above we mean
that the given year has a month with the given day. For example, February
29th is a proper date only for a leap year. We do not mean to include the
Seconds in this notion; in particular, we do not mean to require
implementations to check for the “missing hour” that occurs when Daylight
Savings Time starts in the spring.
"""
"""
43
type Duration is delta implementation-defined range
implementation-defined;
"""

GNAT provides an extension package GNAT.Calendar that adds
hour/minute/day-of-week and some other utilities... BUT
"""
procedure Split_At_Locale
(Date : Ada.Calendar.Time;
Year : out Ada.Calendar.Year_Number;
Month : out Ada.Calendar.Month_Number;
Day : out Ada.Calendar.Day_Number;
Hour : out Hour_Number;
Minute : out Minute_Number;
Second : out Second_Number;
Sub_Second : out Second_Duration);
-- Split a standard Ada.Calendar.Time value in date data (Year, Month,
Day)
-- and Time data (Hour, Minute, Second, Sub_Second). This version of
Split
-- utilizes the time zone and DST bias of the locale (equivalent to
Clock).
-- Due to this simplified behavior, the implementation does not require
-- expensive system calls on targets such as Windows.
-- WARNING: Split_At_Locale is no longer aware of historic events and
may
-- produce inaccurate results over DST changes which occurred in the
past.
"""

--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/

Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?

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

 copy mid

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

 copy link   Newsgroups: comp.lang.python
Path: i2pn2.org!i2pn.org!news.swapon.de!fu-berlin.de!uni-berlin.de!not-for-mail
From: pyt...@mrabarnett.plus.com (MRAB)
Newsgroups: comp.lang.python
Subject: Re: Why does datetime.timedelta only have the attributes 'days' and
'seconds'?
Date: Tue, 19 Apr 2022 21:06:20 +0100
Lines: 20
Message-ID: <mailman.159.1650398970.20749.python-list@python.org>
References: <20220416160028.tmedahn64gdpzsov@hjp.at>
<mailman.127.1650124831.20749.python-list@python.org>
<slrnt5ma4a.41c.jon+usenet@raven.unequivocal.eu>
<20220417072651.6tcttzdx4mhptv2v@hjp.at>
<mailman.147.1650180414.20749.python-list@python.org>
<87ee1t49ae.fsf@hornfels.zedat.fu-berlin.de>
<slrnt5t99q.7j14.jon+usenet@raven.unequivocal.eu>
<8735i944im.fsf@hornfels.zedat.fu-berlin.de>
<slrnt5tdf3.7j14.jon+usenet@raven.unequivocal.eu>
<87r15t2nci.fsf@hornfels.zedat.fu-berlin.de>
<54pt5h55ee3b81oct6j35put5na51lk56h@4ax.com>
<99e46fb0-390d-cea6-5fe4-5befe786a56a@mrabarnett.plus.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.uni-berlin.de H5tZgeMFICujNnSLZrCHMA/PXqfbovdUf+kDntcCn72g==
Return-Path: <python@mrabarnett.plus.com>
X-Original-To: python-list@python.org
Delivered-To: python-list@mail.python.org
Authentication-Results: mail.python.org; dkim=pass
reason="2048-bit key; unprotected key"
header.d=plus.com header.i=@plus.com header.b=rUUIaMQP;
dkim-adsp=none (unprotected policy); dkim-atps=neutral
X-Spam-Status: OK 0.072
X-Spam-Evidence: '*H*': 0.87; '*S*': 0.01; '2022': 0.05;
'subject:Why': 0.07; 'from:addr:python': 0.09; 'later,': 0.09;
'received:192.168.1.64': 0.09; '+0200,': 0.16; '[snip]': 0.16;
'explanatory': 0.16; 'from:addr:mrabarnett.plus.com': 0.16;
'from:name:mrab': 0.16; 'message-id:@mrabarnett.plus.com': 0.16;
'received:plus.net': 0.16; 'subject:does': 0.16;
'subject:seconds': 0.16; 'wrote:': 0.16; 'tue,': 0.19; 'to:addr
:python-list': 0.20; "what's": 0.22; 'header:User-Agent:1': 0.30;
'seem': 0.31; 'takes': 0.31; 'received:192.168.1': 0.32; 'but':
0.32; 'same': 0.34; 'header:In-Reply-To:1': 0.34; 'trying': 0.35;
'skip:2 20': 0.35; 'subject:skip:d 10': 0.35; 'year': 0.36;
"it's": 0.37; 'received:192.168': 0.37; 'happen': 0.40; 'seconds':
0.40; 'day,': 0.62; 'received:212': 0.62; 'days': 0.62; 'per':
0.68; 'day.': 0.68; 'following:': 0.69; 'julian': 0.69; 'little':
0.73; 'subject:have': 0.75; 'astronomical': 0.84; 'merely': 0.84;
'subject:days': 0.84; 'subject:only': 0.84; '365': 0.88;
'supplement': 0.91; 'earth': 0.93
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=plus.com; s=042019;
t=1650398782; bh=6QUZuB5CyEBFQo4+0edRU5djlMImKHd9QX922c/uaPU=;
h=Date:Subject:To:References:From:In-Reply-To;
b=rUUIaMQP1RVIVYJ7CTdMASlB9/dg3kShrjS1Z72WAWf2eWPCHF4V492+ff9MdindZ
ZgfA9Vxl3/BOez2rq+f68rWnDwqlBk9xOfmYo9HDJvP94rjVccaP57hmrAyQugyaLD
xoxZrN4L/wLNQavj1ykb1xb4vYdDQm4liVl9xx4G7KnNz8Zykki3q07AVpFY+peibs
2tw4Gg5jGb2D6OUSQOjuYfnb+R29ued5lTPXhsiOEg8O6gXkUb0HQ7gRhqOBaEFrhD
vdiaziU3Z+QHx9NpBOhpGMX+JWSfWOp+M1i+3ZIuUSLcPJ+ZiCLk/EPUiy/kXo+4By
Ui9kI2de7ZGpQ==
X-Clacks-Overhead: "GNU Terry Pratchett"
X-CM-Score: 0.00
X-CNFS-Analysis: v=2.4 cv=DfIEF9hW c=1 sm=1 tr=0 ts=625f163e
a=0nF1XD0wxitMEM03M9B4ZQ==:117 a=0nF1XD0wxitMEM03M9B4ZQ==:17
a=SO8S7t-XJe_s-KJb:21 a=IkcTkHD0fZMA:10 a=baMOtTqHwvAlcxp8xBMA:9
a=QEXdDO2ut3YA:10 a=-WGtrfRMxLqBHcxsy0AX:22
X-AUTH: mrabarnett@:2500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Content-Language: en-GB
In-Reply-To: <54pt5h55ee3b81oct6j35put5na51lk56h@4ax.com>
X-CMAE-Envelope: MS4xfMvv7fSh3Y5BmemH5BGDBuuOmElOa9bUaoXJ7GtXTtEKDEIRS08S0bMgjxTzOvLM/4euvYT3Xrk1gAVVbWLcBtYHczX4mfX+8V+M/A4S2LSIGBwMqVg6
GLyNckfFG5ilQRRZZJV1NZ0QoZlqwbgVVMTb5+7vYw+YSMYOoI0vGBv8efiYslQmoP+Adn+AUO/vHMRSaeTbs80YlDN0uRabGeY=
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: <99e46fb0-390d-cea6-5fe4-5befe786a56a@mrabarnett.plus.com>
X-Mailman-Original-References: <20220416160028.tmedahn64gdpzsov@hjp.at>
<mailman.127.1650124831.20749.python-list@python.org>
<slrnt5ma4a.41c.jon+usenet@raven.unequivocal.eu>
<20220417072651.6tcttzdx4mhptv2v@hjp.at>
<mailman.147.1650180414.20749.python-list@python.org>
<87ee1t49ae.fsf@hornfels.zedat.fu-berlin.de>
<slrnt5t99q.7j14.jon+usenet@raven.unequivocal.eu>
<8735i944im.fsf@hornfels.zedat.fu-berlin.de>
<slrnt5tdf3.7j14.jon+usenet@raven.unequivocal.eu>
<87r15t2nci.fsf@hornfels.zedat.fu-berlin.de>
<54pt5h55ee3b81oct6j35put5na51lk56h@4ax.com>
 by: MRAB - Tue, 19 Apr 2022 20:06 UTC

On 2022-04-19 19:23, Dennis Lee Bieber wrote:
> On Tue, 19 Apr 2022 15:51:09 +0200, "Loris Bennett"
> <loris.bennett@fu-berlin.de> declaimed the following:
>
>>If I am merely trying to represent part a very large number of seconds
>>as a number of years, 365 days per year does not seem that controversial
>
> The Explanatory Supplement to the Astronomical Almanac (table 15.3)
> defines the /day/ as 24hrs->1440mins->86400secs BUT defines the Julian
> /year/ as 365.25 days.
>
So, a /day/ is a solar day, as distinct from a sidereal day.

What's the difference?

Well, a "sidereal day" is how long it takes for the Earth to rotate on
its axis, but as it's also orbiting the Sun in the same direction,
midday won't happen until a little later, hence "solar day".

[snip]

Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?

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

 copy mid

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

 copy link   Newsgroups: comp.lang.python
Path: i2pn2.org!rocksolid2!i2pn.org!news.swapon.de!fu-berlin.de!uni-berlin.de!not-for-mail
From: bar...@barrys-emacs.org (Barry)
Newsgroups: comp.lang.python
Subject: Re: Why does datetime.timedelta only have the attributes 'days' and
'seconds'?
Date: Tue, 19 Apr 2022 21:53:02 +0100
Lines: 14
Message-ID: <mailman.160.1650401739.20749.python-list@python.org>
References: <54pt5h55ee3b81oct6j35put5na51lk56h@4ax.com>
<CD746BA2-108B-4D45-BBD5-D2134B155C90@barrys-emacs.org>
Mime-Version: 1.0 (1.0)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Trace: news.uni-berlin.de rkJe5awYnt4SUHGQNZpWEQPiZWuuGdNLJoqNi2Nz74lg==
Return-Path: <barry@barrys-emacs.org>
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.054
X-Spam-Evidence: '*H*': 0.91; '*S*': 0.02; 'subject:Why': 0.07;
'cc:addr:python-list': 0.09; 'from:addr:barry': 0.09;
'received:217.70': 0.09; 'received:217.70.178': 0.09;
'received:gandi.net': 0.09; 'received:mail.gandi.net': 0.09;
'cc:no real name:2**0': 0.14; '2022,': 0.16; 'barry': 0.16;
'from:addr:barrys-emacs.org': 0.16; 'message-id:@barrys-
emacs.org': 0.16; 'subject:does': 0.16; 'subject:seconds': 0.16;
'wrote:': 0.16; 'cc:addr:python.org': 0.20; 'cc:2**0': 0.25;
'unless': 0.32; 'year,': 0.33; 'header:In-Reply-To:1': 0.34;
'subject:skip:d 10': 0.35; 'year': 0.36; 'really': 0.37; 'skip:o
10': 0.61; 'less': 0.65; 'day': 0.66; 'received:217': 0.67; 'per':
0.68; 'day.': 0.68; 'century': 0.69; 'subject:have': 0.75;
'century.': 0.84; 'eventually': 0.84; 'leap': 0.84;
'subject:days': 0.84; 'subject:only': 0.84; 'centuries': 0.91
In-Reply-To: <54pt5h55ee3b81oct6j35put5na51lk56h@4ax.com>
X-Mailer: iPad Mail (19E258)
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: <CD746BA2-108B-4D45-BBD5-D2134B155C90@barrys-emacs.org>
X-Mailman-Original-References: <54pt5h55ee3b81oct6j35put5na51lk56h@4ax.com>
 by: Barry - Tue, 19 Apr 2022 20:53 UTC

> On 19 Apr 2022, at 19:38, Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:
>
> * I /think/ this is the year used for leap-day calculations, and why some
> leap centuries are skipped as it is really less than a quarter day per
> year, so eventually one gets to over-correcting by a day.

Leap century is skip unless it’s a leap quadra century.

Barry

Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?

<slrnt5uarp.7j14.jon+usenet@raven.unequivocal.eu>

 copy mid

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

 copy link   Newsgroups: comp.lang.python
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: jon+use...@unequivocal.eu (Jon Ribbens)
Newsgroups: comp.lang.python
Subject: Re: Why does datetime.timedelta only have the attributes 'days' and
'seconds'?
Date: Tue, 19 Apr 2022 21:36:57 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 13
Message-ID: <slrnt5uarp.7j14.jon+usenet@raven.unequivocal.eu>
References: <54pt5h55ee3b81oct6j35put5na51lk56h@4ax.com>
<CD746BA2-108B-4D45-BBD5-D2134B155C90@barrys-emacs.org>
<mailman.160.1650401739.20749.python-list@python.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 19 Apr 2022 21:36:57 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="ffc18bdace02b751447b1386f7d0c1db";
logging-data="31245"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18Th9NZ0dgIttiYUiSoOTzP4p3KY4oey1w="
User-Agent: slrn/1.0.3 (Linux)
Cancel-Lock: sha1:YzZ8ecG/n24v12CBQgHJ9u6Yb5Q=
 by: Jon Ribbens - Tue, 19 Apr 2022 21:36 UTC

On 2022-04-19, Barry <barry@barrys-emacs.org> wrote:
>> On 19 Apr 2022, at 19:38, Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:
>> * I /think/ this is the year used for leap-day calculations, and
>> why some leap centuries are skipped as it is really less than a
>> quarter day per year, so eventually one gets to over-correcting
>> by a day.
>
> Leap century is skip unless it’s a leap quadra century.

Indeed, which is why "leap=not year & 3" works for years in
range(1901, 2100). Which I have found useful before when
programming in an assembly language that has no division
operation ;-)

Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?

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

 copy mid

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

 copy link   Newsgroups: comp.lang.python
Path: i2pn2.org!i2pn.org!news.swapon.de!fu-berlin.de!uni-berlin.de!not-for-mail
From: random...@fastmail.com (Random832)
Newsgroups: comp.lang.python
Subject: Re: Why does datetime.timedelta only have the attributes 'days' and
'seconds'?
Date: Tue, 19 Apr 2022 18:10:11 -0400
Lines: 42
Message-ID: <mailman.161.1650406235.20749.python-list@python.org>
References: <0b6be8d41b466ddd60787ddaecd26d063e961fc0.camel@anode.ca>
<mailman.87.1649948491.20749.python-list@python.org>
<slrnt5gf1l.41c.jon+usenet@raven.unequivocal.eu>
<20220416084411.kkfjtz2bjl5wqo5o@hjp.at>
<mailman.123.1650098653.20749.python-list@python.org>
<slrnt5li7k.41c.jon+usenet@raven.unequivocal.eu>
<slrnt5lk8c.41c.jon+usenet@raven.unequivocal.eu>
<20220416160028.tmedahn64gdpzsov@hjp.at>
<mailman.127.1650124831.20749.python-list@python.org>
<slrnt5ma4a.41c.jon+usenet@raven.unequivocal.eu>
<20220417072651.6tcttzdx4mhptv2v@hjp.at>
<mailman.147.1650180414.20749.python-list@python.org>
<87ee1t49ae.fsf@hornfels.zedat.fu-berlin.de>
<19bc3cf1-cd89-4f88-82ae-09983a502b9e@www.fastmail.com>
Mime-Version: 1.0
Content-Type: text/plain
X-Trace: news.uni-berlin.de EDG8WvvT5JEN2ySlloRghweSFrW8Im+G6ZuIbPYzpAgg==
Return-Path: <random832@fastmail.com>
X-Original-To: python-list@python.org
Delivered-To: python-list@mail.python.org
Authentication-Results: mail.python.org; dkim=pass
reason="2048-bit key; unprotected key"
header.d=fastmail.com header.i=@fastmail.com header.b=W2oMc7u3;
dkim-adsp=pass; dkim-atps=neutral
X-Spam-Status: OK 0.019
X-Spam-Evidence: '*H*': 0.96; '*S*': 0.00; 'fairly': 0.05; 'string':
0.07; 'subject:Why': 0.07; 'apparently': 0.09; 'datetime': 0.09;
'obviously': 0.09; 'cheers,': 0.11; 'url:mailman': 0.15;
'supported': 0.15; '*think*': 0.16; '2022,': 0.16; 'awkward':
0.16; 'bennett': 0.16; 'daylight': 0.16; 'from:addr:fastmail.com':
0.16; 'incorrectly.': 0.16; 'indeed': 0.16; 'languages.': 0.16;
'naive': 0.16; 'parsing': 0.16; 'received:10.202': 0.16;
'received:10.202.2': 0.16; 'received:internal': 0.16;
'received:messagingengine.com': 0.16; 'seconds.': 0.16;
'subject:does': 0.16; 'subject:seconds': 0.16; 'timezone': 0.16;
'wrote:': 0.16; 'problem': 0.16; 'python': 0.16; 'tue,': 0.19;
'to:addr:python-list': 0.20; 'i.e.': 0.22; 'skip:p 30': 0.23;
'run': 0.23; 'url-ip:188.166.95.178/32': 0.25; 'url-
ip:188.166.95/24': 0.25; 'url:listinfo': 0.25; 'url-
ip:188.166/16': 0.25; 'seems': 0.26; 'do,': 0.26; 'library': 0.26;
'>>>': 0.28; 'expect': 0.28; 'header:User-Agent:1': 0.30; 'url-
ip:188/8': 0.31; 'think': 0.32; "doesn't": 0.32; '13,': 0.32;
'objects': 0.32; 'but': 0.32; 'header:In-Reply-To:1': 0.34;
'skip:2 20': 0.35; 'subject:skip:d 10': 0.35; 'received:66': 0.35;
'people': 0.36; 'missing': 0.37; 'currently': 0.37; 'really':
0.37; 'using': 0.37; "it's": 0.37; 'class': 0.37; 'way': 0.38;
'least': 0.39; 'this,': 0.39; 'use': 0.39; 'seconds': 0.40;
'something': 0.40; 'want': 0.40; 'format': 0.62; 'here': 0.62;
'hours': 0.63; 'between': 0.63; 'clear': 0.64; 'becomes': 0.64;
'received:userid': 0.66; 'day': 0.66; 'numbers': 0.67; 'back':
0.67; 'interested': 0.68; 'model.': 0.69; 'skip:e 60': 0.69;
'within': 0.69; 'you.': 0.71; 'easy': 0.74; 'subject:have': 0.75;
'formatting': 0.76; 'period.': 0.76; 'signature': 0.76; 'need.':
0.84; '(such': 0.84; 'leap': 0.84; 'periods': 0.84; 'realise':
0.84; 'strings': 0.84; 'subject:days': 0.84; 'subject:only': 0.84;
'surprised': 0.84
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h=
cc:content-type:date:date:from:from:in-reply-to:in-reply-to
:message-id:mime-version:references:reply-to:sender:subject
:subject:to:to; s=fm1; t=1650406232; x=1650492632; bh=npEr9bTn2P
0yAfJu0lZ8xCzMjy48gFW/3S3AJIEvR18=; b=W2oMc7u3n1xRyA2i3x8HTEPbo5
/29/kmJ8F3dHH3OxkbxVET1Wyp90bsmYD5rSAqto8ZX22PAFvlFcxQ3WSXKqyv6W
BtCBsaFjAiKqfbdCTlb/y9hVqw/qo06mTMncRjiiO8wS59Cq/m4dMgb7bCGKMqNT
XomeGMUJVz0DNhDFdhUq3vpXKXZyzgtPMi2chGWLe6h7c/JiFPP8RAgi6TKLrQqw
WTJ9onVbJ+u0Tgz68RvlKpoloKFwMLCPyLLYg3GpSEVAV/uGDq25Q/efZxtm4KaJ
FO6plLJVQGbkL3tfD/UA/01q7kHP4dm5tGcvfoQkwJHdU7lOdrDCTGxdGPkA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=cc:content-type:date:date:from:from
:in-reply-to:in-reply-to:message-id:mime-version:references
:reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy
:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1650406232; x=
1650492632; bh=npEr9bTn2P0yAfJu0lZ8xCzMjy48gFW/3S3AJIEvR18=; b=h
Mmvlpli4Dq5dOHvHFU0aUQl6vFaWXj7OejkR8hy1xbjsMPXziBsNbCHuXKOxg05C
vrVu+Z1GyuWkaV857VAXFAptrzkW1XpdVM/SmU5KDDh8h0JtNptEgMYQhh5MRrwp
/46S4Fbs/SvEvuNx149GNyAf3Wz99Q0yAYNjzN0KG0jFPc01sKzGuSn1Mu0ZTgDX
2c++ckckvqxwIqxSBVbw+/6LKEE8TjcVtBhrUdxplN0DAaUcDIF0jOD5I7rCavVC
WxE58kSb80aO2Y0MDZuCfBco39/qcbXBB6RqJulXXfAp7i9Qy5mRktYRbNHHPSNe
3J4p86qPC9ssJOgCRFmTA==
X-ME-Sender: <xms:WDNfYjKKAAd9USTDNHTQZw88g-PDbMpRkNteIPxap58Z5Al5J_GeHg>
<xme:WDNfYnLfcYHmPK2N8a187sCvTRppojU7Gg-yDkr-nSyWDB_DUHBXjVKnVapUQSjDx
LUw2yI9outh4imW>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrvddtgedgtdeiucetufdoteggodetrfdotf
fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomheptfgrnhgu
ohhmkeefvdcuoehrrghnughomhekfedvsehfrghsthhmrghilhdrtghomheqnecuggftrf
grthhtvghrnhepieeltdevvdejvdefteetgeehvddukeeigfehjeegudeigeelfeduveff
heegtddtnecuffhomhgrihhnpehphihthhhonhdrohhrghenucevlhhushhtvghrufhiii
gvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehrrghnughomhekfedvsehfrghsthhm
rghilhdrtghomh
X-ME-Proxy: <xmx:WDNfYrvntDwSluIDF71fEzADtIuj4O6Cx7xN_FdS707kju_9PAKSBQ>
<xmx:WDNfYsYYgHCd3jOAdeva6VG4bZQjZSZ4pMUzEkMltlU3AcYY4Y4q5A>
<xmx:WDNfYqY0mMP8tGPtOx_OsuKi9iK6qCnSHxHX4_MMh4vW2xQXC9xJkA>
<xmx:WDNfYjlJcdAfsiMyp-WbkIpHHjokeOWVAMWEXg7M70iN9gChjfvC5w>
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.7.0-alpha0-568-g521196dd5d-fm-20220414.001-g521196dd
In-Reply-To: <87ee1t49ae.fsf@hornfels.zedat.fu-berlin.de>
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: <19bc3cf1-cd89-4f88-82ae-09983a502b9e@www.fastmail.com>
X-Mailman-Original-References: <0b6be8d41b466ddd60787ddaecd26d063e961fc0.camel@anode.ca>
<mailman.87.1649948491.20749.python-list@python.org>
<slrnt5gf1l.41c.jon+usenet@raven.unequivocal.eu>
<20220416084411.kkfjtz2bjl5wqo5o@hjp.at>
<mailman.123.1650098653.20749.python-list@python.org>
<slrnt5li7k.41c.jon+usenet@raven.unequivocal.eu>
<slrnt5lk8c.41c.jon+usenet@raven.unequivocal.eu>
<20220416160028.tmedahn64gdpzsov@hjp.at>
<mailman.127.1650124831.20749.python-list@python.org>
<slrnt5ma4a.41c.jon+usenet@raven.unequivocal.eu>
<20220417072651.6tcttzdx4mhptv2v@hjp.at>
<mailman.147.1650180414.20749.python-list@python.org>
<87ee1t49ae.fsf@hornfels.zedat.fu-berlin.de>
 by: Random832 - Tue, 19 Apr 2022 22:10 UTC

On Tue, Apr 19, 2022, at 07:11, Loris Bennett wrote:
> I now realise that timedelta is not really what I need. I am interested
> solely in pure periods, i.e. numbers of seconds, that I can convert back
> and forth from a format such as

A timedelta *is* a pure period. A timedelta of one day is 86400 seconds.

The thing you *think* timedelta does [making a day act as 23 or 25 hours across daylight saving boundaries etc], that you *don't* want it to do, is something it *does not actually do*. I don't know how this can be made more clear to you.

timedelta is what you need. if you think it's not, it's because you're using datetime incorrectly.

The real problem is that naive datetime objects [without using either a fixed timezone offset like the built-in utc, or a library like pytz] are not fit for any purpose.

If you use pytz correctly [which is unfortunately awkward due to leaky abstractions and mismatches between the datetime model works and how most people expect datetimes with timezones to work], you will indeed get 24 hours from timedelta(days=1)

>>> et = pytz.timezone('America/New_York')
>>> et.normalize(et.localize(datetime.datetime(2022,3,12,12,0,0)) + datetime.timedelta(days=1))
datetime.datetime(2022, 3, 13, 13, 0, tzinfo=<DstTzInfo 'America/New_York' EDT-1 day, 20:00:00 DST>)

you can see here that 2022-03-12T12:00-0500 + timedelta(days=1) correctly becomes 2022-03-13T13:00-0400, 24 hours later.

As far as I know, Python doesn't even have a way to represent "1 day" [or 1 month, 1 year] as a context-dependent-length interval (the thing you think timedelta does), at least not within the standard library and the datetime model.

> 11-22::44:55
>
> (These are the lengths of time a job has run on an HPC system - leap
> seconds and time zones are of no relevance).
>
> It is obviously fairly easy to rustle up something to do this, but I am
> surprised that this is not baked into Python (such a class also seems to
> be missing from R). I would have thought that periods crop up all over
> the place and therefore formatting as strings and parsing of string
> would be supported natively by most modern languages. Apparently not.
>
> Cheers,
>
> Loris
>
> --
> This signature is currently under construction.
> --
> https://mail.python.org/mailman/listinfo/python-list

Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?

<87sfq8nuqv.fsf@hornfels.zedat.fu-berlin.de>

 copy mid

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

 copy link   Newsgroups: comp.lang.python
Path: i2pn2.org!i2pn.org!news.swapon.de!fu-berlin.de!uni-berlin.de!not-for-mail
From: loris.be...@fu-berlin.de (Loris Bennett)
Newsgroups: comp.lang.python
Subject: Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
Date: Wed, 20 Apr 2022 08:18:00 +0200
Organization: Freie Universitaet Berlin
Lines: 28
Message-ID: <87sfq8nuqv.fsf@hornfels.zedat.fu-berlin.de>
References: <0b6be8d41b466ddd60787ddaecd26d063e961fc0.camel@anode.ca>
<mailman.87.1649948491.20749.python-list@python.org>
<slrnt5gf1l.41c.jon+usenet@raven.unequivocal.eu>
<20220416084411.kkfjtz2bjl5wqo5o@hjp.at>
<mailman.123.1650098653.20749.python-list@python.org>
<slrnt5li7k.41c.jon+usenet@raven.unequivocal.eu>
<slrnt5lk8c.41c.jon+usenet@raven.unequivocal.eu>
<20220416160028.tmedahn64gdpzsov@hjp.at>
<mailman.127.1650124831.20749.python-list@python.org>
<slrnt5ma4a.41c.jon+usenet@raven.unequivocal.eu>
<20220417072651.6tcttzdx4mhptv2v@hjp.at>
<mailman.147.1650180414.20749.python-list@python.org>
<87ee1t49ae.fsf@hornfels.zedat.fu-berlin.de>
<19bc3cf1-cd89-4f88-82ae-09983a502b9e@www.fastmail.com>
<mailman.161.1650406235.20749.python-list@python.org>
Mime-Version: 1.0
Content-Type: text/plain
X-Trace: news.uni-berlin.de 4vUEqx5km6HPXlheIisqpQpW0iMquOuEeQpW8S9Ey877h6
Cancel-Lock: sha1:UTuFVQqltNuBGblx9+/o34PeBdU=
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
 by: Loris Bennett - Wed, 20 Apr 2022 06:18 UTC

Random832 <random832@fastmail.com> writes:

> On Tue, Apr 19, 2022, at 07:11, Loris Bennett wrote:

>> I now realise that timedelta is not really what I need. I am
>> interested solely in pure periods, i.e. numbers of seconds, that I
>> can convert back and forth from a format such as
>
> A timedelta *is* a pure period. A timedelta of one day is 86400
> seconds.
>
> The thing you *think* timedelta does [making a day act as 23 or 25
> hours across daylight saving boundaries etc], that you *don't* want it
> to do, is something it *does not actually do*. I don't know how this
> can be made more clear to you.

I have now understood this.

> timedelta is what you need. if you think it's not, it's because you're
> using datetime incorrectly.

It is what I need. It just doesn't do the trivial format conversion I
(apparently incorrectly) expected. However, I can implement the format
conversion myself.

[snip (35 lines)]
--
This signature is currently under construction.

Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?

<87o80wntxv.fsf@hornfels.zedat.fu-berlin.de>

 copy mid

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

 copy link   Newsgroups: comp.lang.python
Path: i2pn2.org!i2pn.org!news.niel.me!aioe.org!news.uzoreto.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: loris.be...@fu-berlin.de (Loris Bennett)
Newsgroups: comp.lang.python
Subject: Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
Date: Wed, 20 Apr 2022 08:35:24 +0200
Organization: Freie Universitaet Berlin
Lines: 105
Message-ID: <87o80wntxv.fsf@hornfels.zedat.fu-berlin.de>
References: <20220416160028.tmedahn64gdpzsov@hjp.at>
<mailman.127.1650124831.20749.python-list@python.org>
<slrnt5ma4a.41c.jon+usenet@raven.unequivocal.eu>
<20220417072651.6tcttzdx4mhptv2v@hjp.at>
<mailman.147.1650180414.20749.python-list@python.org>
<87ee1t49ae.fsf@hornfels.zedat.fu-berlin.de>
<slrnt5t99q.7j14.jon+usenet@raven.unequivocal.eu>
<8735i944im.fsf@hornfels.zedat.fu-berlin.de>
<slrnt5tdf3.7j14.jon+usenet@raven.unequivocal.eu>
<87r15t2nci.fsf@hornfels.zedat.fu-berlin.de>
<54pt5h55ee3b81oct6j35put5na51lk56h@4ax.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Trace: news.uni-berlin.de AH+x+GM3im1Ivqt2U0DfFAQ/xNpfSGaeiMX0Kvp0b2A9l9
Cancel-Lock: sha1:pano17MnCD9apzD2CWOcWVWO5cY=
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
 by: Loris Bennett - Wed, 20 Apr 2022 06:35 UTC

Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:

> On Tue, 19 Apr 2022 15:51:09 +0200, "Loris Bennett"
> <loris.bennett@fu-berlin.de> declaimed the following:
>
>>If I am merely trying to represent part a very large number of seconds
>>as a number of years, 365 days per year does not seem that controversial
>
> The Explanatory Supplement to the Astronomical Almanac (table 15.3)
> defines the /day/ as 24hrs->1440mins->86400secs BUT defines the Julian
> /year/ as 365.25 days.

That is interesting. However, I am not claiming that the definition of
a year as 365 24-hour days is in any way correct, merely that it is a
possible definition and one that is potentially handy if one wants to
represent large numbers of seconds in a more readable way.

> It goes on to also give (for my copy -- length of year at 1990):
> Tropical (equinox to equinox) 365.2421897 days *
> Sidereal (fixed star to fixed star) 365.25636 days
> Anomalistic (perihelion to perihelion) 365.25964 days
> Eclipse (moon's node to moon's node) 346.26005
> Gaussian (Kepler's law /a/=1) 365.25690
> Julian 365.25
>
> Length of the month (I interpret this as lunar month):
> Synodic (new moon to new moon) 29.53059 days
> Tropical (as with year) 27.32158
> Sidereal (as with year) 27.32166
> Anomalistic (perigee to perigee) 27.55455
> Draconic (node to node) 27.21222
>
> * I /think/ this is the year used for leap-day calculations, and why some
> leap centuries are skipped as it is really less than a quarter day per
> year, so eventually one gets to over-correcting by a day.
>
> Of course, this book also has a footnote giving the speed of light as
> 1.80261750E12 Furlongs/Fortnight <G>

And of course I should have been asking why timedelta doesn't provide an
easy way to format the period as a number of fortnights :-)

> However, as soon you incorporate units that are not SI seconds you have
> to differentiate between pure duration (based on SI seconds) and civil time
> (which may jump when leap seconds are added/subtracted, time zones are
> crossed, or daylight savings time goes into [or out of] effect).
>
> For the most part, Python's datetime module seems to account for civil
> time concepts, not monotonic durations.

That indeed seems to be the case and the lack of trivial formatting
options for monotonic durations is what surprises me.

> The Ada standard separates "duration" (as a measure of elapsed time, in
> fixed point seconds) from "time" (a private type in Ada.Calendar -- which
> does NOT define hours/minutes... It has Year 1901..2399, Month 1..12, Day
> 1..31, Day_duration 0.0..86400.0). There are functions to create a Time
> from components, split a Time into components, compare two times, add a
> Duration to a Time, subtract a Duration from a Time, and subtract a Time
> from a Time (getting a Duration). Oh, and a function to get Time from
> system clock. Per the standard, the Time Zone used is implementation
> defined (so one needs to read the implementation manual to find out what a
> Time really notates). Of note:
> """
> 26.a/1
> To be honest: {8652/0106} {AI95-00160-01} By "proper date" above we mean
> that the given year has a month with the given day. For example, February
> 29th is a proper date only for a leap year. We do not mean to include the
> Seconds in this notion; in particular, we do not mean to require
> implementations to check for the “missing hour” that occurs when Daylight
> Savings Time starts in the spring.
> """
> """
> 43
> type Duration is delta implementation-defined range
> implementation-defined;
> """
>
> GNAT provides an extension package GNAT.Calendar that adds
> hour/minute/day-of-week and some other utilities... BUT
> """
> procedure Split_At_Locale
> (Date : Ada.Calendar.Time;
> Year : out Ada.Calendar.Year_Number;
> Month : out Ada.Calendar.Month_Number;
> Day : out Ada.Calendar.Day_Number;
> Hour : out Hour_Number;
> Minute : out Minute_Number;
> Second : out Second_Number;
> Sub_Second : out Second_Duration);
> -- Split a standard Ada.Calendar.Time value in date data (Year, Month,
> Day)
> -- and Time data (Hour, Minute, Second, Sub_Second). This version of
> Split
> -- utilizes the time zone and DST bias of the locale (equivalent to
> Clock).
> -- Due to this simplified behavior, the implementation does not require
> -- expensive system calls on targets such as Windows.
> -- WARNING: Split_At_Locale is no longer aware of historic events and
> may
> -- produce inaccurate results over DST changes which occurred in the
> past.
> """
--
This signature is currently under construction.

Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?

<57527be9-884f-4ee4-b285-34eaa4dfbae6n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.lang.python
X-Received: by 2002:ad4:4351:0:b0:444:46fe:6cf with SMTP id q17-20020ad44351000000b0044446fe06cfmr16133706qvs.47.1650475939433;
Wed, 20 Apr 2022 10:32:19 -0700 (PDT)
X-Received: by 2002:a05:620a:11b0:b0:69e:6238:153a with SMTP id
c16-20020a05620a11b000b0069e6238153amr12789463qkk.403.1650475939233; Wed, 20
Apr 2022 10:32:19 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.python
Date: Wed, 20 Apr 2022 10:32:19 -0700 (PDT)
In-Reply-To: <87o80wntxv.fsf@hornfels.zedat.fu-berlin.de>
Injection-Info: google-groups.googlegroups.com; posting-host=92.10.205.101; posting-account=aKzvzQoAAAAnYB7N4xfKf_Ihdfau7aG5
NNTP-Posting-Host: 92.10.205.101
References: <20220416160028.tmedahn64gdpzsov@hjp.at> <mailman.127.1650124831.20749.python-list@python.org>
<slrnt5ma4a.41c.jon+usenet@raven.unequivocal.eu> <20220417072651.6tcttzdx4mhptv2v@hjp.at>
<mailman.147.1650180414.20749.python-list@python.org> <87ee1t49ae.fsf@hornfels.zedat.fu-berlin.de>
<slrnt5t99q.7j14.jon+usenet@raven.unequivocal.eu> <8735i944im.fsf@hornfels.zedat.fu-berlin.de>
<slrnt5tdf3.7j14.jon+usenet@raven.unequivocal.eu> <87r15t2nci.fsf@hornfels.zedat.fu-berlin.de>
<54pt5h55ee3b81oct6j35put5na51lk56h@4ax.com> <87o80wntxv.fsf@hornfels.zedat.fu-berlin.de>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <57527be9-884f-4ee4-b285-34eaa4dfbae6n@googlegroups.com>
Subject: Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
From: breamore...@gmail.com (Mark Lawrence)
Injection-Date: Wed, 20 Apr 2022 17:32:19 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 2
 by: Mark Lawrence - Wed, 20 Apr 2022 17:32 UTC

On Wednesday, April 20, 2022 at 7:35:45 AM UTC+1, Loris Bennett wrote:

Just in case nobody has mentioned it how about https://dateutil.readthedocs.io/en/stable/

Pages:12
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor