Python 2.7.6 help with modules

Chris Angelico rosuav at gmail.com
Sun Feb 9 02:50:01 CET 2014


On Sun, Feb 9, 2014 at 12:46 PM, Scott W Dunning <swdunning at cox.net> wrote:
> On Feb 8, 2014, at 5:56 PM, Chris Angelico <rosuav at gmail.com> wrote:
>>
>> Carry on with that method - work out the number of minutes, and then
>> the "hours_etc" which has the rest. Then do the same to split off
>> hours, and then days. See how you go!
>
> I did it similar to that but I went backwards.  I started with number of weeks and went down to seconds remaining.  Would the result still be the same if the order of the code went the other way (i.e.. from minutes to weeks instead of the way I did it from weeks to seconds)?
>

The result will be the same. You can work either way. Working from the
smallest up lets you work in different formats - maybe you want to
suppress "0 weeks, 0 days" if it's less than a day, for instance.
Working from the largest down means you can simply write things out as
you get them, and they'll be in the right order for a human to read
(look back up to my aside where I show assembly-language number
display, and you'll see that the digits come out in the wrong order).

>> [1] For the purposes of this exercise, I'm pretending that this is
>> Unix time and has no leap seconds. Technically, when you write out
>> HH:MM:SS, the HH field can go from 00 to 23, the MM field can go from
>> 00 to 59, and the SS field can go from 00 to 61 - yes, it's possible
>> to have *two* consecutive leap seconds, although this has never yet
>> happened. But for this, we're working in a system that has seconds
>> going from 00 to 59
>
>
> I honestly do not know what leap seconds are but I’ll take your word for it.  lol

Heh. I mentioned them for completeness only. Look 'em up on Wikipedia
if you like; some years are a smidge longer than 365 or 366 days, by
either one or two seconds. Almost NEVER significant to every-day work,
but you'll see some time formatting libraries that mention them
(mainly because the SS field can go up to 61).

ChrisA



More information about the Python-list mailing list