Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #69089 > unrolled thread

YADTR (Yet Another DateTime Rant)

Back to article view | Back to comp.lang.python

Contents

  YADTR (Yet Another DateTime Rant) Roy Smith <roy@panix.com> - 2014-03-25 20:58 -0400
    Re: YADTR (Yet Another DateTime Rant) Ethan Furman <ethan@stoneleaf.us> - 2014-03-25 18:19 -0700
    Re: YADTR (Yet Another DateTime Rant) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-26 09:27 +0000
    Re: YADTR (Yet Another DateTime Rant) Skip Montanaro <skip@pobox.com> - 2014-03-26 08:37 -0500
      Re: YADTR (Yet Another DateTime Rant) Roy Smith <roy@panix.com> - 2014-03-26 08:04 -0700
        Re: YADTR (Yet Another DateTime Rant) Skip Montanaro <skip@pobox.com> - 2014-03-26 10:39 -0500
          Re: YADTR (Yet Another DateTime Rant) Marko Rauhamaa <marko@pacujo.net> - 2014-03-26 17:58 +0200
            Re: YADTR (Yet Another DateTime Rant) Skip Montanaro <skip@pobox.com> - 2014-03-26 11:34 -0500
              Re: YADTR (Yet Another DateTime Rant) Marko Rauhamaa <marko@pacujo.net> - 2014-03-26 19:13 +0200
              Re: YADTR (Yet Another DateTime Rant) Grant Edwards <invalid@invalid.invalid> - 2014-03-26 19:12 +0000
                Re: YADTR (Yet Another DateTime Rant) Ben Finney <ben+python@benfinney.id.au> - 2014-03-27 07:06 +1100
        Re: YADTR (Yet Another DateTime Rant) Roy Smith <roy@panix.com> - 2014-03-26 11:50 -0400
    Re: YADTR (Yet Another DateTime Rant) Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2014-03-26 15:02 +0100
      Re: YADTR (Yet Another DateTime Rant) Marko Rauhamaa <marko@pacujo.net> - 2014-03-26 16:43 +0200
    Re: YADTR (Yet Another DateTime Rant) Chris Angelico <rosuav@gmail.com> - 2014-03-27 01:12 +1100
      Re: YADTR (Yet Another DateTime Rant) Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-03-27 11:08 +1300
    Re: YADTR (Yet Another DateTime Rant) Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-03-26 19:25 -0400
      Re: YADTR (Yet Another DateTime Rant) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-27 00:16 +0000
        Re: YADTR (Yet Another DateTime Rant) Chris Angelico <rosuav@gmail.com> - 2014-03-27 12:28 +1100
          Re: YADTR (Yet Another DateTime Rant) Roy Smith <roy@panix.com> - 2014-03-26 21:38 -0400
            Re: YADTR (Yet Another DateTime Rant) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-27 08:40 +0000
        Re: YADTR (Yet Another DateTime Rant) Dan Sommers <dan@tombstonezero.net> - 2014-03-27 03:56 +0000
        Re: YADTR (Yet Another DateTime Rant) Johannes Bauer <dfnsonfsduifb@gmx.de> - 2014-03-27 11:22 +0100
          Re: YADTR (Yet Another DateTime Rant) Chris Angelico <rosuav@gmail.com> - 2014-03-27 21:44 +1100
            Re: YADTR (Yet Another DateTime Rant) Johannes Bauer <dfnsonfsduifb@gmx.de> - 2014-03-27 12:05 +0100
              Re: YADTR (Yet Another DateTime Rant) Chris Angelico <rosuav@gmail.com> - 2014-03-27 22:33 +1100
            Re: YADTR (Yet Another DateTime Rant) Johannes Bauer <dfnsonfsduifb@gmx.de> - 2014-03-27 12:25 +0100
              Re: YADTR (Yet Another DateTime Rant) Chris Angelico <rosuav@gmail.com> - 2014-03-27 22:42 +1100
              Re: YADTR (Yet Another DateTime Rant) Skip Montanaro <skip@pobox.com> - 2014-03-27 06:56 -0500
                Re: YADTR (Yet Another DateTime Rant) Marko Rauhamaa <marko@pacujo.net> - 2014-03-27 16:04 +0200
              Re: YADTR (Yet Another DateTime Rant) Chris Angelico <rosuav@gmail.com> - 2014-03-27 23:20 +1100
              Re: YADTR (Yet Another DateTime Rant) Skip Montanaro <skip@pobox.com> - 2014-03-27 08:01 -0500
              Re: YADTR (Yet Another DateTime Rant) Terry Reedy <tjreedy@udel.edu> - 2014-03-27 17:10 -0400
              Re: YADTR (Yet Another DateTime Rant) Ethan Furman <ethan@stoneleaf.us> - 2014-03-27 17:04 -0700
              Re: YADTR (Yet Another DateTime Rant) Terry Reedy <tjreedy@udel.edu> - 2014-03-27 21:46 -0400
                Re: YADTR (Yet Another DateTime Rant) Roy Smith <roy@panix.com> - 2014-03-27 21:59 -0400
                  Re: YADTR (Yet Another DateTime Rant) Terry Reedy <tjreedy@udel.edu> - 2014-03-27 22:24 -0400
                  Re: YADTR (Yet Another DateTime Rant) Chris Angelico <rosuav@gmail.com> - 2014-03-28 14:03 +1100
            Re: YADTR (Yet Another DateTime Rant) Roy Smith <roy@panix.com> - 2014-03-27 08:52 -0400
              Re: YADTR (Yet Another DateTime Rant) Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2014-03-27 15:12 +0100
              Re: YADTR (Yet Another DateTime Rant) Chris Angelico <rosuav@gmail.com> - 2014-03-28 01:15 +1100
              Re: YADTR (Yet Another DateTime Rant) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-27 23:41 +0000
                Re: YADTR (Yet Another DateTime Rant) Roy Smith <roy@panix.com> - 2014-03-27 20:29 -0400
                  Re: YADTR (Yet Another DateTime Rant) Ben Finney <ben+python@benfinney.id.au> - 2014-03-28 11:43 +1100
                  Re: YADTR (Yet Another DateTime Rant) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-28 11:11 +0000
                    Re: YADTR (Yet Another DateTime Rant) Roy Smith <roy@panix.com> - 2014-03-28 08:30 -0400
                      Re: YADTR (Yet Another DateTime Rant) Marko Rauhamaa <marko@pacujo.net> - 2014-03-28 15:10 +0200
                        Re: YADTR (Yet Another DateTime Rant) Chris Angelico <rosuav@gmail.com> - 2014-03-29 00:19 +1100
                          Re: YADTR (Yet Another DateTime Rant) Roy Smith <roy@panix.com> - 2014-03-28 09:22 -0400
                            Re: YADTR (Yet Another DateTime Rant) Rustom Mody <rustompmody@gmail.com> - 2014-03-28 06:30 -0700
                            Re: YADTR (Yet Another DateTime Rant) Chris Angelico <rosuav@gmail.com> - 2014-03-29 00:32 +1100
                        Re: YADTR (Yet Another DateTime Rant) Roy Smith <roy@panix.com> - 2014-03-28 09:20 -0400
                          Re: YADTR (Yet Another DateTime Rant) Marko Rauhamaa <marko@pacujo.net> - 2014-03-28 16:34 +0200
                      Re: YADTR (Yet Another DateTime Rant) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-28 14:35 +0000
                        Re: YADTR (Yet Another DateTime Rant) Chris Angelico <rosuav@gmail.com> - 2014-03-29 02:25 +1100
    Re: YADTR (Yet Another DateTime Rant) Ethan Furman <ethan@stoneleaf.us> - 2014-03-26 16:33 -0700

Page 1 of 3  [1] 2 3  Next page →

#69089 — YADTR (Yet Another DateTime Rant)

One of my roles on this newsgroup is to periodically whine about 
stupidities in the Python datetime module.  This is one of those times.

I have some code which computes how long ago the sun set.  Being a nice 
pythonista, I'm using a timedelta to represent this value.  It would be 
difficult to imagine a less useful default way to print a timedelta:

previous sunset: -1 day, 22:25:26.295993

The idea of str() is that it's supposed to return a human-friendly 
representation of a value.  Humans do not say things like, "The sun set 
1 day ago plus 22 hours and 25 minutes".

[toc] | [next] | [standalone]

#69091

On 03/25/2014 05:58 PM, Roy Smith wrote:
> One of my roles on this newsgroup is to periodically whine about
> stupidities in the Python datetime module.  This is one of those times.
>
> I have some code which computes how long ago the sun set.  Being a nice
> pythonista, I'm using a timedelta to represent this value.  It would be
> difficult to imagine a less useful default way to print a timedelta:
>
> previous sunset: -1 day, 22:25:26.295993
>
> The idea of str() is that it's supposed to return a human-friendly
> representation of a value.  Humans do not say things like, "The sun set
> 1 day ago plus 22 hours and 25 minutes".

I'm not sure whether to admire you for your stick-to-it-iveness, or pity you for the plight you are in.  Either the 
first or second time I hit a datetime WTF moment I wrote my own wrapper classes.

--
~Ethan~

[toc] | [prev] | [next] | [standalone]

#69111

On 26/03/2014 01:19, Ethan Furman wrote:
> On 03/25/2014 05:58 PM, Roy Smith wrote:
>> One of my roles on this newsgroup is to periodically whine about
>> stupidities in the Python datetime module.  This is one of those times.
>>
>> I have some code which computes how long ago the sun set.  Being a nice
>> pythonista, I'm using a timedelta to represent this value.  It would be
>> difficult to imagine a less useful default way to print a timedelta:
>>
>> previous sunset: -1 day, 22:25:26.295993
>>
>> The idea of str() is that it's supposed to return a human-friendly
>> representation of a value.  Humans do not say things like, "The sun set
>> 1 day ago plus 22 hours and 25 minutes".
>
> I'm not sure whether to admire you for your stick-to-it-iveness, or pity
> you for the plight you are in.  Either the first or second time I hit a
> datetime WTF moment I wrote my own wrapper classes.
>

dateutils for me.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

[toc] | [prev] | [next] | [standalone]

#69125

It's not clear to me what the correct str should be. I think the
desired format changes depending on the relative magnitude of the
timedelta object. For small values (less than a day), I agree, the
behavior is, well, odd.  You can get around that easily enough:

>>> d = datetime.timedelta(seconds=-2)
>>> str(d)
'-1 day, 23:59:58'
>>> "-%s" % -d
'-0:00:02'

The problem gets more challenging once you get into magnitudes > one
day:

>>> e = datetime.timedelta(days=-4, seconds=3605)
>>> e
datetime.timedelta(-4, 3605)
>>> print e
-4 days, 1:00:05

Hmmm... It's printing just what we said, negative four days, positive
one hour, five minutes. Let's try the trick from above:

>>> print -e
3 days, 22:59:55
>>> "-%s" % -e
'-3 days, 22:59:55'

Ehhh... not so much.  The fundamental problem here is the scope of the
minus sign. My trick assumes it applied to the entire string
representation.  It's clear that in the first case that it applies to
the entire displayed value, as there are no spaces. In the second
case, we know it only applies to the days, because it's spitting back
exactly what I fed the constructor.  So, that means the simple minus
sign trick won't work in the third case. Complicating things are that
timedelta objects are normalized internally so that the seconds field
is always non-negative (explaining the weird "-1 day, 23:59:58" string
representation of the first case).

I'm not sure there's a one-size-fits-all solution to this problem. For
offsets of less than a day, I suppose you could argue that the string
representation shouldn't include the "-1 day" bit. Beyond that, I
think you kind of have to live with what it gives you.

Skip

[toc] | [prev] | [next] | [standalone]

#69131

On Wednesday, March 26, 2014 9:37:06 AM UTC-4, Skip Montanaro wrote:

> The problem gets more challenging once you get into magnitudes > one
> day:
> 
> >>> e = datetime.timedelta(days=-4, seconds=3605)
> >>> e
> datetime.timedelta(-4, 3605)
> >>> print e
> -4 days, 1:00:05
> 
> Hmmm... It's printing just what we said, negative four days, positive
> one hour, five minutes. Let's try the trick from above:

No, what you said was "negative four days, positive 3605 seconds".  Why does it make sense to normalize 3605 seconds to "1 hour, 5 seconds", but not extend that normalization to the days portion?

> Complicating things are that timedelta objects are normalized internally so that
> the seconds field is always non-negative

The whole idea of datatypes is to hide the internal representation.  If it's convenient on your platform, you can store timedeltas internally as fempto-years.  That should not affect how it prints.

[toc] | [prev] | [next] | [standalone]

#69132

On Wed, Mar 26, 2014 at 10:04 AM, Roy Smith <roy@panix.com> wrote:
> No, what you said was "negative four days, positive 3605 seconds".

My apologies for not showing all my work, professor. I use datetime
and timedelta objects all the time. I did the arithmetic to go from
3605 to one hour, five minutes in my head.

The point of my post was that there is no obvious one best way to
present negative timedeltas in a human readable form. In my usage it's
not generally a big deal, as most of the time I want to display
datetime objects. In your case, it's obviously a problem. If Tim
thought that timedelta objects would be presented to users as a
regular course of doing business, maybe he would have given them a
strftime() method. I suggest you write a function to format it the way
you want and be done with it.

You might consider taking a crack at a strftime() (and strptime?)
implementation for timedelta objects that uses the ISO 8601 notation
and submit it as a patch for datetimemodule.c. Note though, that the
ISO8601 representation isn't without its own flaws (which might
explain why Tim avoided it BITD):

* It doesn't appear to provide a way to represent fractions of a
second (though perhaps all the fields can be fractional)
* How many days are in a month or a year? (It has format codes for
both. Writing a useful strptime is probably impossible.)
* It has other ambiguities ("M" represents both months and minutes -
what were they thinking?)

Skip

[toc] | [prev] | [next] | [standalone]

#69134

Skip Montanaro <skip@pobox.com>:

> Note though, that the ISO8601 representation isn't without its own
> flaws (which might explain why Tim avoided it BITD):
>
> * It doesn't appear to provide a way to represent fractions of a
> second (though perhaps all the fields can be fractional)
> * How many days are in a month or a year? (It has format codes for
> both. Writing a useful strptime is probably impossible.)
> * It has other ambiguities ("M" represents both months and minutes -
> what were they thinking?)


I don't have the (nonfree) ISO 8601 at hand, but

   <URL: http://www.schemacentral.com/sc/xsd/t-xsd_duration.html>

contains the practical answers -- xsd is one important use case for
str(timedelta), after all.

Fractions of seconds are supported -- the other fields can't be
fractional. The letter "T" separates months and minutes so there's no
ambiguity there.

str(timedelta()), unfortunately probably can't use anything but seconds
since PT1M can be 61 seconds and P1D can be 23 or 25 hours (DST). As you
say, P1M really means one month and P1Y means one year. The ambiguity is
intentional; if you mean to pay your employees monthly, the interval is
one month.


Marko

[toc] | [prev] | [next] | [standalone]

#69136

On Wed, Mar 26, 2014 at 10:58 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Fractions of seconds are supported -- the other fields can't be
> fractional.

Actually, it appears that whatever the last value you give can be
fractionated.  From the Wikipedia page you referenced:

"The smallest value used may also have a decimal fraction, as in
"P0.5Y" to indicate half a year."

> As you say, P1M really means one month and P1Y means one year. The
> ambiguity is intentional; if you mean to pay your employees monthly,
> the interval is one month.

True.  Your comment about monthly intervals makes me realize that you
probably can't map timedelta objects onto this ISO8601 duration
stuff. It seems like if you want to specify "pay my employees on the
first of every month", then timedelta objects are the wrong thing. You
want a recurrence relation, which is a more complex beast. For that,
you want something like dateutil.rrule. There is a good reason that
the internal units of timedelta objects are days, seconds, and
microseconds. They are well-defined outside of a calendar context.

So, I guess Roy is back to square one. He can always roll his own
timedelta subclass and give it a __str__ implementation...

S

[toc] | [prev] | [next] | [standalone]

#69138

Skip Montanaro <skip@pobox.com>:

> There is a good reason that the internal units of timedelta objects
> are days, seconds, and microseconds. They are well-defined outside of
> a calendar context.
>
> So, I guess Roy is back to square one. He can always roll his own
> timedelta subclass and give it a __str__ implementation...

If you don't want to mix the intricacies of calendars to datetime and
timedelta, why use them?

(Epoch) seconds do everything for you unambiguously.

Yes, yes. The physicists ought to stop fricking around with leap
seconds. They should declare a 3000-year moratorium on leap seconds.


Marko

[toc] | [prev] | [next] | [standalone]

#69141

On 2014-03-26, Skip Montanaro <skip@pobox.com> wrote:
> On Wed, Mar 26, 2014 at 10:58 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
>> Fractions of seconds are supported -- the other fields can't be
>> fractional.
>
> Actually, it appears that whatever the last value you give can be
> fractionated.  From the Wikipedia page you referenced:

We're still just papering-over the basic problem: the entire
time/calendar system use by "western civilization" is a mess.  I don't
know a lot about other systems in use, but from what I have seen they
were all pretty much just as bad.  We should fix the basic problem
first, then I bet the Python library problems will sort themselves out
pretty easily.

Of course to simplify matters, we're going to have to stop worrying so
much about seasons and whether it's light or dark outside...

-- 
Grant Edwards               grant.b.edwards        Yow! Hey, wait
                                  at               a minute!!  I want a
                              gmail.com            divorce!! ... you're not
                                                   Clint Eastwood!!

[toc] | [prev] | [next] | [standalone]

#69142

Grant Edwards <invalid@invalid.invalid> writes:

> We're still just papering-over the basic problem: the entire
> time/calendar system use by "western civilization" is a mess. I don't
> know a lot about other systems in use, but from what I have seen they
> were all pretty much just as bad. We should fix the basic problem
> first, then I bet the Python library problems will sort themselves out
> pretty easily.

I see from my calendar that 1 April is still several days away. So I
wonder how serious you are: we should forestall dealing with the reality
of calendars, until the world fixes our difficulties for us?

> Of course to simplify matters, we're going to have to stop worrying so
> much about seasons and whether it's light or dark outside...

Not too serious, I suppose.

So what *do* you recommend we do? It's easy to point at the real world
and say it's messy and distasteful to deal with, but that's a big part
of the job we take on as programmers.

-- 
 \            “… Nature … is seen to do all things Herself and through |
  `\         herself of own accord, rid of all gods.” —Titus Lucretius |
_o__)                                                 Carus, c. 40 BCE |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#69133

On Mar 26, 2014, at 11:39 AM, Skip Montanaro wrote:

> The point of my post was that there is no obvious one best way to
> present negative timedeltas in a human readable form.

I agree that there are a number of possible representations which might make sense.  But, using negative days and positive hours:minutes:seconds is just bizarre.  I can't think of any possible application where that would be the desired format.


---
Roy Smith
roy@panix.com

[toc] | [prev] | [next] | [standalone]

#69127

On 26-03-14 01:58, Roy Smith wrote:
> One of my roles on this newsgroup is to periodically whine about 
> stupidities in the Python datetime module.  This is one of those times.
>
> I have some code which computes how long ago the sun set.  Being a nice 
> pythonista, I'm using a timedelta to represent this value.  It would be 
> difficult to imagine a less useful default way to print a timedelta:
>
> previous sunset: -1 day, 22:25:26.295993
>
> The idea of str() is that it's supposed to return a human-friendly 
> representation of a value.  Humans do not say things like, "The sun set 
> 1 day ago plus 22 hours and 25 minutes".
There is a difference between how people say things and what is useful.
I remember when I was studying logarithms, a negative number like -5.73
was written down as ̅6.27 (with a bar only over the six). That notation
had the advantage that the part after the decimal point stayed the same
if you added or subtracted whole numbers. Even if that would change the
sign.

I can't give an honest estimation of how useful this notation is because
I don't use the datetime module often enough. But I can imagine that those
who wrote the module and I expect used it often found it a useful
representation.

-- 
Antoon Pardon

[toc] | [prev] | [next] | [standalone]

#69130

Antoon Pardon <antoon.pardon@rece.vub.ac.be>:

> On 26-03-14 01:58, Roy Smith wrote:
>> previous sunset: -1 day, 22:25:26.295993
>>
>> The idea of str() is that it's supposed to return a human-friendly 
>> representation of a value.  Humans do not say things like, "The sun set 
>> 1 day ago plus 22 hours and 25 minutes".
> There is a difference between how people say things and what is useful.

There is a standard timedelta representation:

  <URL: http://www.schemacentral.com/sc/xsd/t-xsd_duration.html>

  <URL: http://en.wikipedia.org/wiki/ISO_8601#Durations>

If timedelta() were created today, it really should use that one because
it is the only standard one, even though few people would use that in a
human interface.

Thus:

   -P1DT22H25M26.295993S


Marko

[toc] | [prev] | [next] | [standalone]

#69128

On Thu, Mar 27, 2014 at 1:02 AM, Antoon Pardon
<antoon.pardon@rece.vub.ac.be> wrote:
> There is a difference between how people say things and what is useful.
> I remember when I was studying logarithms, a negative number like -5.73
> was written down as ̅6.27 (with a bar only over the six). That notation
> had the advantage that the part after the decimal point stayed the same
> if you added or subtracted whole numbers. Even if that would change the
> sign.

That's highly significant with logs, especially when you're working
with base 10 logs.

>>> math.log10(1234)
3.091315159697223
>>> math.log10(12340)
4.091315159697223
>>> math.log10(123400)
5.091315159697223
>>> math.log10(1234000)
6.091315159697223
>>> math.log10(12.34)
1.0913151596972228
>>> math.log10(1.234)
0.09131515969722287
>>> math.log10(.1234)
-0.9086848403027772
>>> math.log10(.01234)
-1.9086848403027772

By showing those last ones as 1̅.091... and 2̅.091..., you emphasize
the floating-point nature of the data: everything after the decimal is
the mantissa, and everything before the decimal is the exponent. I
can't say for sure as I don't really use that, but I can imagine that
there might be something similar with dates and times - it's three
days ago at 2:51, not two days and 21:09 ago.

Or maybe it's just "print it out in a way that more closely matches
the internal representation, to simplify debugging" :)

ChrisA

[toc] | [prev] | [next] | [standalone]

#69149

Chris Angelico wrote:
> By showing those last ones as 1̅.091... and 2̅.091..., you emphasize
> the floating-point nature of the data: everything after the decimal is
> the mantissa, and everything before the decimal is the exponent.

The reason for writing them that way is so that you
can look the last part up in your log tables to
find the antilog.

I can't think of any corresponding justification
for timedeltas.

-- 
Greg

[toc] | [prev] | [next] | [standalone]

#69152

On Tue, 25 Mar 2014 20:58:27 -0400, Roy Smith <roy@panix.com> declaimed the
following:

>One of my roles on this newsgroup is to periodically whine about 
>stupidities in the Python datetime module.  This is one of those times.
>
>I have some code which computes how long ago the sun set.  Being a nice 
>pythonista, I'm using a timedelta to represent this value.  It would be 
>difficult to imagine a less useful default way to print a timedelta:
>
>previous sunset: -1 day, 22:25:26.295993
>
>The idea of str() is that it's supposed to return a human-friendly 
>representation of a value.  Humans do not say things like, "The sun set 
>1 day ago plus 22 hours and 25 minutes".

	Makes sense to me -- the key being time DELTA... IE, a difference from
some (unspecified) instance in time...

	If you want an instance of time, you need to add some known instance
and the delta value.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#69156

On Wed, 26 Mar 2014 19:25:45 -0400, Dennis Lee Bieber wrote:

> On Tue, 25 Mar 2014 20:58:27 -0400, Roy Smith <roy@panix.com> declaimed
> the following:
> 
>>One of my roles on this newsgroup is to periodically whine about
>>stupidities in the Python datetime module.  This is one of those times.
>>
>>I have some code which computes how long ago the sun set.  Being a nice
>>pythonista, I'm using a timedelta to represent this value.  It would be
>>difficult to imagine a less useful default way to print a timedelta:
>>
>>previous sunset: -1 day, 22:25:26.295993
>>
>>The idea of str() is that it's supposed to return a human-friendly
>>representation of a value.  Humans do not say things like, "The sun set
>>1 day ago plus 22 hours and 25 minutes".
> 
> 	Makes sense to me -- the key being time DELTA... IE, a difference 
> from some (unspecified) instance in time...
> 
> 	If you want an instance of time, you need to add some known 
> instance and the delta value.


I think you have missed the point of the rant. Roy is not ranting that he 
has a timedelta. He wants a timedelta. He is ranting that the timedelta 
displays in a totally unintuitive fashion. Paraphrasing:

"the previous sunset was (one day less 22 hours and 25 minutes) ago"

instead of 

"the previous sunset was (1 hour and 35 minutes) ago"

where the parts in the brackets come directly from the timedelta object.

I think that you misread Roy's example as:

"1 day plus 22 hours 25 minutes ago"

instead of:

"1 day ago plus 22 hours 25 minutes"

(that is, 22 hours and 25 minutes after 1 day ago).

The problem here, I believe, is that there are two ways of interpreting 
remainders for negative numbers. Dividing -5 by 2 can give either -2 with 
remainder -1, or -3 with remainder +1.

Mathematically, it is *usually* more useful to go with the version with 
the positive remainder, and that's what Python does. But I think it's the 
wrong choice for timedelta. Let's take a simple example: a timedelta of 
30 hours. What's that in days and hours?

py> divmod(30, 24)
(1, 6)

That makes perfect intuitive sense: 30 hours is 1 day with 6 hours 
remaining. In human-speak, we'll say that regardless of whether the 
timedelta is positive or negative: we'll say "1 day and 6 hours from now" 
or "1 day and 6 hours ago". But when we specify the sign:

py> divmod(-30, 24)
(-2, 18)

If an event happened 30 hours ago, it is correct to say that it occurred 
"18 hours after 2 days ago", but who talks that way?




-- 
Steven D'Aprano
http://import-that.dreamwidth.org/

[toc] | [prev] | [next] | [standalone]

#69162

On Thu, Mar 27, 2014 at 11:16 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> If an event happened 30 hours ago, it is correct to say that it occurred
> "18 hours after 2 days ago", but who talks that way?

That response demonstrates real genius. Rue the datetime? Who talks like that?

ChrisA

[toc] | [prev] | [next] | [standalone]

#69163

In article <mailman.8597.1395883727.18130.python-list@python.org>,
 Chris Angelico <rosuav@gmail.com> wrote:

> On Thu, Mar 27, 2014 at 11:16 AM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
> > If an event happened 30 hours ago, it is correct to say that it occurred
> > "18 hours after 2 days ago", but who talks that way?
> 
> That response demonstrates real genius. Rue the datetime? Who talks like that?

"I had a dangling pointer error, and blew my stack to half past last 
wednesday"

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.python

csiph-web