On Sat, Apr 16, 2022, at 13:35, Peter J. Holzer wrote:
> When adding a timedeltacal object to a datetime, the fields are added
> from most to least significant: First a new date is computed by
> advancing the number of months specified [TODO: Research how other
> systems handle overflow (e.g. 2022-
> On 18 Apr 2022, at 13:01, Peter J. Holzer wrote:
>
> On 2022-04-16 20:25:45 +0100, Barry wrote:
>> Suggest that you start with the use cases that you want supported.
>> Then you can turn them into a set of tests to check that the solution works.
>
> Writing test cases is always a good idea
On 2022-04-16 20:25:45 +0100, Barry wrote:
> Suggest that you start with the use cases that you want supported.
> Then you can turn them into a set of tests to check that the solution works.
Writing test cases is always a good idea :-)
I have now written a first set of test cases:
https://git.hjp
On 2022-04-17 10:15:54 +0200, Peter J. Holzer wrote:
> On 2022-04-17 06:08:54 +1000, Chris Angelico wrote:
> > On Sun, 17 Apr 2022 at 03:37, Peter J. Holzer wrote:
> > > Therefore a new class (provisionally called timedeltacal, because it is
> > > calendaric, not absolute) should be added to datet
Am Sun, Apr 17, 2022 at 11:10:01AM +1200 schrieb Greg Ewing:
> On 17/04/22 9:17 am, Karsten Hilbert wrote:
> > Take this medication for 1 month !
> >
> >is quite likely to mean "take it for 28 days".
>
> Except when your doctor prescribes 90 days worth of tablets,
It *still* means "take for 2
On Sun, 17 Apr 2022 at 18:17, Peter J. Holzer wrote:
>
> On 2022-04-17 06:08:54 +1000, Chris Angelico wrote:
> > On Sun, 17 Apr 2022 at 03:37, Peter J. Holzer wrote:
> > > Datetime arithmetic in the real world is typically not done in seconds,
> > > but in calendaric units: Hours, days, weeks, mo
On 2022-04-17 06:08:54 +1000, Chris Angelico wrote:
> On Sun, 17 Apr 2022 at 03:37, Peter J. Holzer wrote:
> > Datetime arithmetic in the real world is typically not done in seconds,
> > but in calendaric units: Hours, days, weeks, months, years, ...
> > The problem is that several of these have v
On 17/04/22 9:17 am, Karsten Hilbert wrote:
Take this medication for 1 month !
is quite likely to mean "take it for 28 days".
Except when your doctor prescribes 90 days worth of tablets,
they come boxes of 84 (6 cards * 14 tablets), and the pharmacist
dutifully opens a box, cuts off an
Am Sat, Apr 16, 2022 at 07:35:51PM +0200 schrieb Peter J. Holzer:
> So I'll start by gathering some feedback
> here with a rough sketch.
> [TODO: Research how other systems handle overflow
> (e.g. 2022-01-31 + 1 month: 2022-02-31 doesn't exist)],
That is context dependant:
Take this med
On Sun, 17 Apr 2022 at 03:37, Peter J. Holzer wrote:
> Datetime arithmetic in the real world is typically not done in seconds,
> but in calendaric units: Hours, days, weeks, months, years, ...
> The problem is that several of these have varying lengths:
>
> * 1 minute may be 60 or 61 seconds (theo
> On 16 Apr 2022, at 18:38, Peter J. Holzer wrote:
>
> I intend to take this to python-ideas, but I'm not currently subscribed
> there and I think I should probably do a bit of research before
> proposing something over there. So I'll start by gathering some feedback
> here with a rough sketch
On 2022-04-16 19:35:51 +0200, Peter J. Holzer wrote:
> Note that t + d - d is in general not equal to t.
>
> We can't cnange the semantics of datetime - datetime, so there must be a
> function to compute the difference between to datetimes as a
> timedeltacal. It could be a method on datetime (may
I intend to take this to python-ideas, but I'm not currently subscribed
there and I think I should probably do a bit of research before
proposing something over there. So I'll start by gathering some feedback
here with a rough sketch.
Datetime arithmetic in the real world is typically not done in
13 matches
Mail list logo
