Hi Tim, Hi Dave,

On Sun, Nov 8, 2020 at 5:27 PM tim Rowledge <tim at rowledge.org> wrote:

>
>
> > On 2020-11-08, 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.
> >
> [snip]
> >> 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.
>
> The FileList simply uses the no-idea-about-TZ code and happened to get it
> right by accident ;-)
>
> There is actually a fairly simple, though tacky solution.
>
>
> !DirectoryEntry methodsFor: 'access' stamp: 'tpr 11/8/2020 17:18'!
> modificationDateAndTime
>         "The DateAndTime my entry in the file system was last modified."
>         ^ DateAndTime fromSeconds: modificationTime - DateAndTime
> localOffsetSeconds! !
>
> Obviously required for creationTimeAndDate too.
>
> An alternative that would approach from the creation end would be to
> subtract the localOffsetSeconds in the
> DirectoryEntry>>#setDirectory:name:creationTime:modificationTime:fileSize:
> method - but then we'd also have to fix the FileList and all the other
> senders of #modificationTime & #creationTime to use DateAndTime. Not that
> we  shouldn't fix those - looking at some of them  I suspect some
> interesting bugs might have been caused by the errant TZ factor.
>

OK, it's done in the latest VM sources.  Make a new VM, set the image
header flag via e.g.

    Smalltalk vmParameterAt: 48 put: ((Smalltalk vmParameterAt: 48) bitOr:
128)

and now times from both the FilePlugin and the FileAttributesPlugin are in
UTC seconds from the epoch.

Backwards compatibility is maintained.  Images without the bit set will get
local times from the File plugins.  Rum the image on an older VM and times
will always be local, but the flag bit should be preserved, so is can be
saved on an older VM, but when run on the newer, if the flag was set, times
should be delivered in UTC.

_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20201108/2ab23f7f/attachment-0001.html>