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

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

time module vs. datetime module: plain language for beginners

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

Contents

  time module vs. datetime module: plain language for beginners Jinghui Niu <niujinghui@gmail.com> - 2015-03-25 14:16 -0700
    Re: time module vs. datetime module: plain language for beginners Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-03-26 10:36 +1100
    Re: time module vs. datetime module: plain language for beginners Ian Kelly <ian.g.kelly@gmail.com> - 2015-03-25 17:49 -0600
    Re: time module vs. datetime module: plain language for beginners Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-03-26 00:01 +0000
    Re: time module vs. datetime module: plain language for beginners Jinghui Niu <niujinghui@gmail.com> - 2015-03-27 17:31 -0700
      Re: time module vs. datetime module: plain language for beginners Ian Kelly <ian.g.kelly@gmail.com> - 2015-03-27 19:07 -0600

#87983 — time module vs. datetime module: plain language for beginners

I am learning python programming. One thing that gives me a lot of confusion is the division of labours between the time module and the datetime module.

As it turns out to be, time module is not only about time, it's about date too. And datetime doesn't natively support timezone, you have to create one for yourself. 

Why duplicate datetime module? What is the design rationale between this division? Can't we just have one unified module that deals with dates and times? Could someone please list some situations where the two modules are actually useful in their own ways respectively?

Explanation with not too much jargon is highly appreciated. Thanks in advance.

[toc] | [next] | [standalone]

#87996

On Thu, 26 Mar 2015 08:16 am, Jinghui Niu wrote:

> I am learning python programming. One thing that gives me a lot of
> confusion is the division of labours between the time module and the
> datetime module.
> 
> As it turns out to be, time module is not only about time, it's about date
> too. And datetime doesn't natively support timezone, you have to create 
> one for yourself.
> 
> Why duplicate datetime module? What is the design rationale between this
> division? Can't we just have one unified module that deals with dates and
> times? Could someone please list some situations where the two modules are
> actually useful in their own ways respectively?
> 
> Explanation with not too much jargon is highly appreciated. Thanks in
> advance.

The time module is written in C, and is mostly interface to low-level
operating system functions. The datetime module is written in Python. It
would be painful to write the time module in Python, or the datetime module
in C, so they are separate.

py> import time
py> import datetime
py> time.__file__
'/usr/local/lib/python3.3/lib-dynload/time.cpython-33m.so'
py> datetime.__file__
'/usr/local/lib/python3.3/datetime.py'


There are other designs possible. For example, the datetime module could be
written in Python, and it could import an accelerator module for the C
parts:

    from _datetime import *


In fact, it already does that! But the private accelerator C datetime
doesn't include the contents of time, so there are still two public
modules.

Why didn't the time functions just get moved into _datetime? As with most of
these things, the answer is probably for historical reasons. You would need
to look far back in the history of Python to see how those two modules
evolved over the years, but my guess is that the very first version of each
had no overlap, and the overlap has just developed since then.

The oldest version of Python I have is version 1.5, and it has a time module
but no datetime module. So my guess is that time was written first, as an
interface to the operating system time routines, in C. Then, some versions
later, a pure-Python datetime module was added, and then later still an
accelerated C _datetime module was added. That's my guess.

I cannot remember the last time I have needed to import both time and
datetime from the same module. I usually only import one, or the other. For
example, I might do:

time.sleep(3)

which doesn't require the datetime module.


-- 
Steven

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

#87999

On Wed, Mar 25, 2015 at 3:16 PM, Jinghui Niu <niujinghui@gmail.com> wrote:
> I am learning python programming. One thing that gives me a lot of confusion is the division of labours between the time module and the datetime module.
>
> As it turns out to be, time module is not only about time, it's about date too. And datetime doesn't natively support timezone, you have to create one for yourself.
>
> Why duplicate datetime module? What is the design rationale between this division? Can't we just have one unified module that deals with dates and times? Could someone please list some situations where the two modules are actually useful in their own ways respectively?
>
> Explanation with not too much jargon is highly appreciated. Thanks in advance.

They have fairly different focuses. Notice that in the standard
library table of contents, they're not even listed in the same
section. datetime is listed under "8.Data Types" whereas time falls
under "16. Generic Operating System Services". That pretty much sums
it up: the datetime module exists to implement convenient data types
for representing dates and times. The time module mostly provides
low-level analogues of C APIs and system calls, e.g. stuff that you
might expect to find in time.h if you were working in C.

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

#88004

On 25/03/2015 23:49, Ian Kelly wrote:
> On Wed, Mar 25, 2015 at 3:16 PM, Jinghui Niu <niujinghui@gmail.com> wrote:
>> I am learning python programming. One thing that gives me a lot of confusion is the division of labours between the time module and the datetime module.
>>
>> As it turns out to be, time module is not only about time, it's about date too. And datetime doesn't natively support timezone, you have to create one for yourself.
>>
>> Why duplicate datetime module? What is the design rationale between this division? Can't we just have one unified module that deals with dates and times? Could someone please list some situations where the two modules are actually useful in their own ways respectively?
>>
>> Explanation with not too much jargon is highly appreciated. Thanks in advance.
>
> They have fairly different focuses. Notice that in the standard
> library table of contents, they're not even listed in the same
> section. datetime is listed under "8.Data Types" whereas time falls
> under "16. Generic Operating System Services". That pretty much sums
> it up: the datetime module exists to implement convenient data types
> for representing dates and times. The time module mostly provides
> low-level analogues of C APIs and system calls, e.g. stuff that you
> might expect to find in time.h if you were working in C.
>

Let's not forget the calendar module, although I've forgotten the last 
time I used it as that was so many years ago.

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

Mark Lawrence

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

#88192

On Wednesday, March 25, 2015 at 2:17:03 PM UTC-7, Jinghui Niu wrote:
> I am learning python programming. One thing that gives me a lot of confusion is the division of labours between the time module and the datetime module.
> 
> As it turns out to be, time module is not only about time, it's about date too. And datetime doesn't natively support timezone, you have to create one for yourself. 
> 
> Why duplicate datetime module? What is the design rationale between this division? Can't we just have one unified module that deals with dates and times? Could someone please list some situations where the two modules are actually useful in their own ways respectively?
> 
> Explanation with not too much jargon is highly appreciated. Thanks in advance.

Thank you all very much for such a great explanation. I have a follow-up question here: what is the best practice in dealing with repeating date/time? I see neither date module nore datetime module natively supports such datatype right now. Thanks.

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

#88195

On Fri, Mar 27, 2015 at 6:31 PM, Jinghui Niu <niujinghui@gmail.com> wrote:
> On Wednesday, March 25, 2015 at 2:17:03 PM UTC-7, Jinghui Niu wrote:
>> I am learning python programming. One thing that gives me a lot of confusion is the division of labours between the time module and the datetime module.
>>
>> As it turns out to be, time module is not only about time, it's about date too. And datetime doesn't natively support timezone, you have to create one for yourself.
>>
>> Why duplicate datetime module? What is the design rationale between this division? Can't we just have one unified module that deals with dates and times? Could someone please list some situations where the two modules are actually useful in their own ways respectively?
>>
>> Explanation with not too much jargon is highly appreciated. Thanks in advance.
>
> Thank you all very much for such a great explanation. I have a follow-up question here: what is the best practice in dealing with repeating date/time? I see neither date module nore datetime module natively supports such datatype right now. Thanks.

Do you mean recurrence rules like "every three hours" or "every two
weeks" or "the third Saturday of every month"? There's nothing
specific in the standard library for this, but check out the
python-dateutil third-party package, specifically the dateutil.rrule
module.

[toc] | [prev] | [standalone]

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

csiph-web