DirectoryEntryFile>>modification
Locked
DirectoryEntryFile>>modification
 
|
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. 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. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Useful random insult:- The wheel's spinning but the hamster's dead. |
Re: DirectoryEntryFile>>modification
|
|
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 |
Re: DirectoryEntryFile>>modification
|
|
> On 2020-11-08, at 4:57 PM, David T. Lewis <[hidden email]> 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. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Useful random insult:- He fell out of the ugly tree and hit every branch on the way down. |
Re: DirectoryEntryFile>>modification
|
|
In reply to this post by David T. Lewis
Hi David, Hi Tim,
> On Nov 8, 2020, at 4:57 PM, David T. Lewis <[hidden email]> 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 > > |
Re: DirectoryEntryFile>>modification
|
|
In reply to this post by timrowledge
Hi Tim, Hi Dave, On Sun, Nov 8, 2020 at 5:27 PM tim Rowledge <[hidden email]> wrote:
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 |
Re: DirectoryEntryFile>>modification
|
|
On Sun, Nov 08, 2020 at 10:42:16PM -0800, Eliot Miranda wrote:
> > 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 Cool! Dave |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |