Camillo Bruni-3 wrote > > yep I would say so too... > the major user is zip compression hence no one will ever notice the > possibly flawed implementation :P >
Yes, since the error is internally consistent (zip and unzip cancel each other out), the image doesn't notice. But I manually unzipped an mcz file and the date was way off... I created an issue and uploaded a fix: Issue 5936: DateAndTime DOS conversion http://code.google.com/p/pharo/issues/detail?id=5936 Neither #fromDosTime: nor #asDosTime seem to correctly translate from DateAndTime to DOS timestamps. Delete comment Comment 1 by project member sean.p.denigris, Today (2 hours ago) Fix in inbox: Name: SLICE-Issue-5936-DateAndTime-DOS-conversion-SeanDeNigris.1 * Fix conversion to/from DateAndTime and DOS timestamps. DOS format per http://blogs.msdn.com/b/oldnewthing/archive/2003/09/05/54806.aspx and http://mindprod.com/jgloss/zip.html * Deprecated and renamed DateAndTime>>asDosTime to #asDosTimestamp (it is not a time, but an encoded date/time) * Deprecated and renamed DateAndTime class>>fromDosSeconds: to #fromDosTimestamp (it is not a number of seconds, like a UNIX or Squeak date/time) * Updated ZipArchiveMember to use new method names * Create DosTimestamp class, and move all DOS-related logic out of DateAndTime * Update tests, removing #testAsDosTimeIndependentOfTimezone (they are not independent; DOS timestamps are in local time), and add tests, which all pass Sean -- View this message in context: http://forum.world.st/DateAndTime-asDosTime-tp4630789p4631250.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
