Hi David,  Hi Tim,

> On Nov 8, 2020, at 4:57 PM, David T. Lewis <lewis at mail.msen.com> wrote:
> 
> On Sun, Nov 08, 2020 at 10:58:13AM -0800, tim Rowledge wrote:
>> Something has broken wrt the handling of the DirectoryEntryFile conversion of the file times.
>> 
>> If you open a FileList of some format and look at files you will see
>> the date/time info shown correctly. At least, on Mac & linux; no idea
>> about Windows.
>> 
>> If you inspect
>>   FileDirectory default directoryEntryFor: 'somefileIjustmade.foo'
>> and then in the inspector try 
>>   self modificationDateAndTime
>> you will notice that the date is borked. 
>> 
>> Compare and contrast with 
>>  date fromSeconds: modificationTime
>> and
>>   Time fromSeconds: modificationTime \\ 86400
>> 
>> The issue seems to stem from a confusion about the expected value of the
>> modificationTime. The image code is assuming it is a UTC seconds count
>> and includes the image's known TZ offset to cause the (in my case) 8 hour
>> variance. The VM code (modulo what version I currently have loaded etc etc)
>> is making a TZ (plus Squeak epoch) corrected value from the number provided
>> by the OS call used.
>> 
>> As best I can tell from the versions record some substantial changes got
>> made to the DateAndTime>>fromSeconds: in 2018 so it may have been problematic
>> ever since then.
>> 
> 
> Your analysis sounds right to me.
> 
> The FilePlugin support code converts time stamps for file entries
> into "Squeak time", which means seconds since the Smalltalk epoch.
> In early days of Squeak, this was understood to mean seconds in
> whatever local time zone you happen to have been in. Later, we
> all agreed to let the Smalltalk epoch be measured with respect
> to GMT ("UTC time").
> 
> So the FilePlugin is and always has been broken. It reports file
> time stamps relative to the Smalltalk epoch, but it offsets those
> values to your local time zone, which is something that we now
> recognize as being wrong. It was a convenient shortcut 25 years
> ago when Squeak ran on very simple operating systems, but it is
> an annoying problem now that all of our computers and cell phones
> are fully aware of time zone conventions.
> 
> Fixing this properly would be a challenge. The FilePlugin fix
> in the VM is trivial, but making that change without breaking
> existing images would be quite a trick.

Fixing it is as easy as adding a flag bit to the image header flags that if set specifies the new behaviour, and if set specifies the old behaviour.  I’ll take a look soon.

> 
>> I'd guess that there ought to be a DateAndTime class>fromLocalSeconds: or similar? Timezones hurt my head so I'm very keen to pass the buck to people with a more direct interest in the chronology stuff. The #creationDateAndTime obviously needs the same solution.
>> 
> 
> I think you're on the right track here, although I don't think
> we would want to add this directly to DateAndTime. As Chris would
> probably point out, the API is messy enough already.
> 
> But somebody has figured out how to make this mess behave reasonably
> in the FileList, so it must be fixable.
> 
> Dave
> 
>