Posted to tcl by ro at Mon Mar 12 15:34:46 GMT 2007view raw

  1.  
  2.  
  3. NOW 8.3.5
  4.  
  5. DST @ Yes -> EDT (GMT -0400)
  6. file mtime c://flashplayer.xpt
  7. 1132334480
  8.  
  9. DST @ No -> EST (GMT -0500)
  10. % file mtime c://flashplayer.xpt
  11. 1132334480
  12.  
  13. ----
  14.  
  15. NOW 8.4.14
  16.  
  17. DST @ Yes -> EDT (GMT -0400)
  18. % file mtime c://flashplayer.xpt
  19. 1132330880
  20.  
  21. DST @ No -> EST (GMT -0500)
  22. % file mtime c://flashplayer.xpt
  23. 1132334480
  24.  
  25. ----
  26.  
  27. NOW 8.5a4
  28.  
  29. DST @ Yes -> EDT (GMT -0400)
  30. % file mtime c://flashplayer.xpt
  31. 1132330880
  32.  
  33. DST @ No -> EST (GMT -0500)
  34. % file mtime c://flashplayer.xpt
  35. 1132334480
  36.  
  37.  

Comments

Posted by patthoyts at Mon Mar 12 16:15:52 GMT 2007 [text] [code]

Some CVS mining shows that the relevant changes to the tclWinFile.c:ToCTime function occurred for 8.4.12 as a response to bugs #926106 (file stat -> ctime is summertime dependant) and #1353840 (windows stat has daylight savings problems)

Posted by ro at Tue Mar 13 05:32:43 GMT 2007 [text] [code]

Turns out it's a FAT32 issue, since it stores localtime and not UTC in the filesystem. I'm going to change the affected partition to NTFS. Thanks Pat for looking it up, appreciated. FAT32 will always act screwy with timestamps as you have to have a lot of support code to find out the actual UTC time and not the "made up" UTC time. You'd have to use the bias from the timezone structs and other timezone functions.