POSIX timestamp doesn't count (literally) past/future leap seconds.
It allows to find out that the timestamp 2**31-1 corresponds to
2038-01-19T03:14:07Z (UTC) regardless of how many leap seconds will
occur before 2038:

  >>> from datetime import datetime, timedelta
  >>> str(datetime(1970,1,1) + timedelta(seconds=2**31-1))
  '2038-01-19 03:14:07'

If you use "right" timezone then mktime() may count leap seconds:

  $ TZ=right/UTC ./python
  >>> import time
  >>> time.mktime((2012, 6, 30, 23, 59, 59, -1, -1, -1))
  1341100823.0
  >>> time.mktime((2012, 6, 30, 23, 59, 60, -1, -1, -1))
  1341100824.0
  >>> time.mktime((2012, 7, 1, 0, 0, 0, -1, -1, -1))
  1341100825.0

It is a different time scale. There are no leap seconds in TAI:

  >>> str(datetime(1970,1,1, 0,0, 10) + timedelta(seconds=1341100825))
  '2012-07-01 00:00:35'

i.e., 2012-07-01 00:00:35 TAI that corresponds to 2012-07-01 00:00:00
UTC. Each positive leap second increases the difference TAI-UTC (on
2015-07-01UTC it will be 36 [1]).

TAI-UTC in the future (more than 6 months) is unknown but it is less
than ~200 seconds until 2100 [2].

It might be convenient to think about datetime as a broken-down
timestamp and therefore

  (datetime(2012,6,30,23,59,60) - epoch) == 
  (datetime(2012,7, 1, 0, 0, 0) - epoch)

The code [3] that silently truncates 60 to 59 when datetime
constructor is called implicitly should retire.

Use case: parse timestamps that might include a leap second [4]

[1] https://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat
[2] http://www.ucolick.org/~sla/leapsecs/year2100.html
[3] https://bugs.python.org/msg155689
[4] http://stackoverflow.com/q/21027639