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.

> 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