Take the 2-minute tour ×

Did anybody notice that the interval of second in Python datetime is [00,61] see the table in the bottom of this page. http://docs.python.org/library/datetime.html#strftime-strptime-behavior


share|improve this question
Day of year also goes from [1, 366] in order to accomodate leap days. –  plaes Feb 16 '12 at 6:56
-1 because +6 for a question answered in the link it contains is ridiculous. –  Wooble Feb 16 '12 at 11:25
+1 because a question that points out an interesting fact that I did not know about is useful. –  EOL Feb 17 '12 at 9:03
@storm: Please don't forget to mark one answer as accepted, if it indeed answered your question. This will even earn you reputation. :) –  EOL Feb 17 '12 at 9:03
@storm, you've been here recently enough, you should definitely mark some questions as accepted when they answer your question. 0% acceptance is just silly. –  Wayne Werner May 1 '12 at 20:34

5 Answers 5

The answer is a little further down in the page:

The range really is 0 to 61; according to the Posix standard this accounts for leap seconds and the (very rare) double leap seconds. The time module may produce and does accept leap seconds since it is based on the Posix standard, but the datetime module does not accept leap seconds in strptime() input nor will it produce them in strftime() output.

This is an interesting behavior, indeed.

share|improve this answer
hmm,I too exiting to ignore the explanation. –  storm Feb 16 '12 at 6:07
I just realized that Python doesn't have a database of leap seconds (akin to tzinfo for timezones) and so doesn't have a way to validate if a certain leap second is legit... this means that conversion to Unix time is lossy: t1=time.strptime("30 Jun 1997 23:59:60", "%d %b %Y %H:%M:%S"); t2=time.strptime("01 Jul 1997 00:00:00", "%d %b %Y %H:%M:%S"), then t1 == t2 yields False as expected, but calendar.timegm(t1) == calendar.timegm(t2) yields True –  berdario Jan 20 at 1:07
@berdario: your example is (accidently?) correct. There is a leap second on 30 Jun 1997. And there is always 86400 seconds in a POSIX day therefore calendar.timegm() returns correct results (the same POSIX timestamp occurs twice in this case). –  J.F. Sebastian Feb 23 at 7:51
The tz database (available via pytz Python package) has a list of leap seconds. You could use it, to check whether given time is a leap second. –  J.F. Sebastian Sep 6 at 0:26

Probably to account for leap seconds.

share|improve this answer

When you have to add leap second it will be helpful to calculate that. You can search on net for leap second. Due to that second range in python is 0-61.

share|improve this answer
Actually it's up to 61 for double leap seconds. –  plaes Feb 16 '12 at 6:57

There is no such thing as a double leap second. There cannot be 62 seconds in a minute. 59, yes. 60, yes. 61, yes. 62, no.


share|improve this answer
Well, can you give a single case of "inverse leap second", e.g. when was the minute, having 59 seconds instead of 60? –  modchan May 22 at 19:19
There have been no examples of a 59 second minute, however in theory there could be. There cannot be a "double leap second" though. –  Greg Hennessy Jul 8 at 19:22

Leap seconds.

It has been the case that there have been 62 seconds in a minute in the past.

It adjusts for the world spinning slower.

Part of this is down to tides. The energy for the tides comes from the rotation of the earth and moon. The result is that the world slows down.

If global warming takes place the oceans get hotter and expand. That is like a skater throwing their arms out, and the spin slows down. That hasn't taken place. The measurement of ocean levels doesn't agree with the rotation measurements. It's likely to be down to problems with the earth's surface moving, which is far larger than the sea level rise.

share|improve this answer
Global warning is not responsible for leap seconds. This is just confusion added to an already complex topic. –  MatthieuW Feb 16 '12 at 9:45

Your Answer


