RE: Web browsers should preserve the file system Last-Modified time of downloaded files

For some additional considerations around timestamps, see http://www.metadataworkinggroup.org/pdf/mwg_guidance.pdf#page=37  (Section 5.3).

I think this is an area where standards are important, needed, and complex.  


-----Original Message-----
From: "Martin J. Dürst" [mailto:duerst@it.aoyama.ac.jp] 
Sent: Wednesday, November 09, 2011 8:52 PM
To: Noah Mendelsohn
Cc: Larry Masinter; Scott Penrose; Karl Dubost; Brolin Empey; www-tag@w3.org List
Subject: Re: Web browsers should preserve the file system Last-Modified time of downloaded files

I very much agree with Noah's last statement: "user agents are free to compete on the quality of their file download implementations."

For the case of pictures (mentioned in the first bullet point), I'd like to point out that pictures contain a 'created' date/time internally, and modern cameras set it correctly (assuming they have their clocks set correctly), so somebody downloading the picture should be able to get at the time it was created without even having to bother about the Web or http or whatever.

Regards,   Martin.

On 2011/11/10 7:35, Noah Mendelsohn wrote:
> Well, my reasons for not wanting to deal with this in the TAG are a 
> bit different. Specifically:
>
> * I think that some of the use cases are not affected by time skew. 
> Very often, files bounce through the Internet, and people just want to 
> see the modified time they started with. Think things like .dll's, 
> photos, etc. I don't really care whether the server clock is in sync 
> with anyone. If I upload a photo, and you download it, I generally 
> want you to get all the timestamps it had when I first put it up. The 
> maintenance of creation vs. modification times is a little unclear to 
> me in these scenarios, but with the possible exception of warning if a 
> modified time winds up "in the future", I can see at least some 
> reasons for just preserving it as the file moves through the network. 
> So, I think this request has some merit.
>
> * With apologies for the fact that Tim suggested bringing this to the 
> TAG, I'm unconvinced it's a TAG-level issue. It seems to me that it's 
> a question of how user agents deal with one of the details of 
> implementing local file save features, and that seems like something 
> to be settled in whatever working group is responsible for the user 
> agent feature (I'm guessing HTML WG in practice these days). If there 
> is no such WG, and no mandated behavior in RFC 2616 or related header 
> specifications (I haven't checked), then I would think user agents are 
> free to compete on the quality of their file download implementations.
>
> Noah
>
> On 11/9/2011 4:03 PM, Larry Masinter wrote:
>> I think the time skew is the determining factor for me...
>>
>> When two systems are on the internet communicating, they *might* be 
>> in sync but often are not. Maybe their clocks are only seconds apart.
>> Maybe the latency between the two systems is small, but I think it is 
>> actually unusual for two systems to be in perfect sync. Whether or 
>> not it is unusual, it *does* happen.
>>
>> Then, the "last-modified" time on the server is server-relative. The 
>> client writes a file in its local file system, you might even get a 
>> file with "last modified" in the future.
>>
>>
>>
>> -----Original Message-----
>> From: Scott Penrose [mailto:scottp@dd.com.au]
>> Sent: Tuesday, November 08, 2011 7:00 PM
>> To: Karl Dubost
>> Cc: Brolin Empey; www-tag@w3.org List
>> Subject: Re: Web browsers should preserve the file system 
>> Last-Modified time of downloaded files
>>
>>>
>>> Le 4 nov. 2011 à 19:18, Brolin Empey a écrit :
>>>> The Web browser should preserve the file system last modified time 
>>>> by default because this time cannot easily be recovered after it is 
>>>> discarded.
>>
>> I have been thinking about this over the last week and which way it 
>> should happen.
>> It is interesting to note that many older backup systems use last 
>> modified as a method to work out if files need incremental backup.
>>
>> The problem is that once you download a file, they are not linked. 
>> The file on your system does not match the remote system. So what 
>> does modified mean?
>>
>> Lets put 3 systems into play.
>>
>> * Server1 - file.png, last modified 2010-01-01
>> * Server 2 - file.png downloaded, last modified 2010-01-01
>> * Client 1 - Download file from Server 2, use if mod since
>>
>> Scenario 1 - Server 2 modifies the PNG (maybe a resize). Last 
>> modified should change to that day (2011-10-01), Client can download.
>>
>> Scenario 2 - Server 1 had updated the logo in 2011-06-01; now Server 
>> 2 downloads from Server 1, preserving date modified as 2011-06-01; 
>> Client now checks if file has changed since last of 2011-10-01 - it 
>> has changed, but now client won't get it. On the other hand, if 
>> Server
>> 2 had set last modified to today 2011-11-09 - it would not be an issue.
>>
>> Scenario 3 - A client downloads a file to Download folder, has a look 
>> at recent files. User would expect to see newest files downloaded 
>> with todays date.
>>
>> I don't think HTTP Clients should preserve modified date time. But 
>> there are exceptions - e.g. WebDAV / SVN over HTTP.
>>
>> Scott
>>
>>
>>
>>
>
>

Received on Saturday, 12 November 2011 03:56:49 UTC