Here is the history of the issue per Martin v. Löwis on python-dev:
"""
This was added with
------------------------------------------------------------------------
r36221 | bcannon | 2004-06-24 03:38:47 +0200 (Do, 24. Jun 2004) | 3 Zeilen
Add compilation of timemodule.c with datetimemodule.c to get
__PyTime_DoubleToTimet().
------------------------------------------------------------------------
So it's clearly intentional. I doubt its desirable, though. If only
__PyTime_DoubleToTimet needs to be duplicated, I'd rather put that
function into a separate C file that gets included twice, instead of including the full timemodule.c into datetimemodule.c.
"""
-- "Sharing functions between C extension modules in stdlib", http://mail.python.org/pipermail/python-dev/2010-June/100587.html
I hope this is non-controversial, but I would like someone to comment on the choice of file name. I chose _timefunc.c to make it more distinguishable from module file names. Ideally, however I would like to see this in either _time.h/_time.c pair (both in Module dir like _math.{c,h}) or in pytime.h/pytime.c (like pymath.{c,h}).
Marking this as "resource usage" because the patch will result in smaller size of datetime module.

_time.c is not supposed to be compiled into an extension. It is similar to _math.c - if you add a line
_math _math.c
to Setup, you get a similar compile error. What needs to be done, however, is to add _time.c to time and datetime lines. See issue9012a.diff.

Thanks. Looks like we need a general solution to the problem of shared (non-module) dependencies in modules.
So all that's needed is a way to stop _time.o showing up twice in MODOBJS in the Makefile, right?
(For some reason, ranlib on OS X doesn't seem to have any problem with multiply-defined symbols; obviously Linux is different.)

I am merging in the nosy list from issue9079 after we had a lengthy discussion there and on IRC about the best way to share code between stdlib extension modules.
For the issue9079, we decided to bring the shared code into python core, but this cannot be a general solution. I still don't see any solution other than exposing C API via a capsule mechanism, but Antoine objected saying that capsule mechanism is for 3rd party modules and should not be used in stdlib.

What about PC/VS7.1/pythoncore.vcproj? Is there some automation in place to keep the project files in sync? ISTM, all the info to generate these should be in setup.py.
The patch looks good, but I am hesitant to commit changes that I cannot test.

No, there's no automated way to keep "legacy" Windows toolchains in sync; short of adopting something like Scons or CMAKE (which I'm *not* suggesting) I don't think I've seen a trustworthy way of doing so.
The PCBuild's "readme.txt" states:
"You can find build directories for older versions of Visual Studio and Visual C++ in the PC directory. The legacy build directories are no longer actively maintained and may not work out of the box."
To date, I believe that the attitude toward these older build files has been "unsupported; use at own risk; patches welcome".

On Wed, Jul 21, 2010 at 3:58 PM, Tim Lesher <report@bugs.python.org> wrote:
..
> To date, I believe that the attitude toward these older build files has been
> "unsupported; use at own risk; patches welcome".
>
OK, I guess there is little risk in committing this patch. I'll do it
later this week unless someone who actually knows anything about VC8
beats me to it. :-)

> it sounds like the patch is ready for commit.
there are two pending patches here:
time.diff - a hack that makes _time.c look like a module while it is not.
add_time_to_vc8_build.diff - a patch for VC 8.0 project file.
I don't like time.diff because it fixes the symptom rather than the core problem. I believe the code that is shared between C modules should be segregated into a true module which would expose its C API via capsule mechanism. Others suggested that this is an overkill and that capsule mechanism is not suitable for the stdlib. On the latter argument, I would like to point that unicodedata already uses capsule mechanism to make itself available to Python's builtin str type.
As I mentioned in msg109219, this situation is not unique to time/datetime. The math and cmath modules similarly use linker tricks to share code in _math.c.
Unassigning because I don't have an informed opinion on add_time_to_vc8_build.diff and cannot move the _time.c issue forward until similar problem is solved for _math.c which I used as the basis for _time.c design.