strftime year 
Author Message
 strftime year

strftime seems to improperly computer the year on the December 31, 2001:

Here is an example program and it's output:

#!/usr/local/bin/python

import time,os

os.environ['TZ']='EST5EDT'

for offset in range(10):
  time_flt=1009757224.0+(offset*3*3600)
  print time_flt,
  print time.strftime('%m/%d/%g %l:%M%P',time.localtime(time_flt))

1009757224.0 12/30/01  7:07pm
1009768024.0 12/30/01 10:07pm
1009778824.0 12/31/02  1:07am
1009789624.0 12/31/02  4:07am
1009800424.0 12/31/02  7:07am
1009811224.0 12/31/02 10:07am
1009822024.0 12/31/02  1:07pm
1009832824.0 12/31/02  4:07pm
1009843624.0 12/31/02  7:07pm
1009854424.0 12/31/02 10:07pm

Note, December 31 should still be year "01".

Am I doing something wrong?



Thu, 15 Jul 2004 23:12:00 GMT  
 strftime year


Quote:
> strftime seems to improperly computer the year on the December 31,
2001:

> Here is an example program and it's output:

> #!/usr/local/bin/python

> import time,os

> os.environ['TZ']='EST5EDT'

> for offset in range(10):
>   time_flt=1009757224.0+(offset*3*3600)
>   print time_flt,
>   print time.strftime('%m/%d/%g %l:%M%P',time.localtime(time_flt))

> 1009757224.0 12/30/01  7:07pm
> 1009768024.0 12/30/01 10:07pm
> 1009778824.0 12/31/02  1:07am
> 1009789624.0 12/31/02  4:07am
> 1009800424.0 12/31/02  7:07am
> 1009811224.0 12/31/02 10:07am
> 1009822024.0 12/31/02  1:07pm
> 1009832824.0 12/31/02  4:07pm
> 1009843624.0 12/31/02  7:07pm
> 1009854424.0 12/31/02 10:07pm

> Note, December 31 should still be year "01".

> Am I doing something wrong?

Amusing, what? It looks like someone has a residual
Y2K bug there. Since python generally uses the existing
C compiler and library in a given environment, that would
be the place to start looking for the bug.

You might also try looking at the bug reports at the
Python project on sourceforge. I doubt seriously
that if it's a Python problem, it would have gone
unreported this long.

John Roth



Fri, 16 Jul 2004 00:12:56 GMT  
 strftime year

Quote:
> strftime seems to improperly computer the year on the December
> 31, 2001:

> Here is an example program and it's output:

> #!/usr/local/bin/python

> import time,os

> os.environ['TZ']='EST5EDT'

> for offset in range(10):
>   time_flt=1009757224.0+(offset*3*3600)
>   print time_flt,
>   print time.strftime('%m/%d/%g %l:%M%P',time.localtime(time_flt))

Ah, on Linux (glibc) the %g operator returns the ISO 8601 year,
based on week numbers.  Just Say No and use %y/%Y instead.

Read the Python Library Reference and follow only the codes there
for portability.

Quote:
> 1009757224.0 12/30/01  7:07pm
> 1009768024.0 12/30/01 10:07pm
> 1009778824.0 12/31/02  1:07am
> 1009789624.0 12/31/02  4:07am
> 1009800424.0 12/31/02  7:07am
> 1009811224.0 12/31/02 10:07am
> 1009822024.0 12/31/02  1:07pm
> 1009832824.0 12/31/02  4:07pm
> 1009843624.0 12/31/02  7:07pm
> 1009854424.0 12/31/02 10:07pm

> Note, December 31 should still be year "01".

Nope, 12/31 is in a different week, which is assigned to 2002.

Quote:
> Am I doing something wrong?

Yup, 'fraid so.  See above.


Fri, 16 Jul 2004 00:18:29 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. GAWK: strftime("%z") and portability (which version of strftime is used in compile?)

2. PL/I 34 years old this year.

3. Is year 2000 a leap year??

4. Localized strftime() output

5. unix time and strftime

6. strftime * date calculations

7. Q: inverse of strftime

8. strftime weirdness

9. time.strftime BUG?

10. strftime: %Z, timezone, and all that

11. strftime ?

12. strftime and windows

 

 
Powered by phpBB® Forum Software