Re: RFD: How To Recognize Bad Javascript Code v0.3
- From: Dr J R Stockton <jrs@xxxxxxxxxxxxxxxxxx>
- Date: Wed, 9 Jan 2008 22:20:31 +0000
In comp.lang.javascript message <4784d81e$0$7149$4c368faf@xxxxxxxxxxxxxx
, Wed, 9 Jan 2008 09:20:15, Wayne <nospam@xxxxxxxxxxxxxx> posted:
Dr J R Stockton wrote:
Your lack of insight is most impressive.the current Windows beta (empty string); and that lastModified is aIt is not a misnomer. It reflects the date the document you are viewing
misnomer because in practice it means "last uploaded to the server".
was last modified. It has nothing to do with "uploading". The FAQ
index.html, while I have been editing the FAQ, has *never* been
uploaded. The date that document.lastModified gives is exactly that,
the date that the document was last Modified. Whether that modification
is by uploading a replacement, direct editing on the server, or by
being generated on the server.
When a document is, for whatever reason, re-uploaded to a server
(perhaps because of a change of server, for instance), it gets a new
Last-Modified header. But if the content of the document, as seen by
the user, is unchanged, it is a disservice to assert that there has been
a modification. It is also a disservice if the change is too slight to
matter to the reader, for example correcting non-misleading typos.[*]
Surely that depends on how the file was uploaded. For example with the
right options on "rsync" the file's last modified timestamp doesn't
change. (It is this filesystem timestamp that is usually used by a
web server when setting the Last-Modified: header, and hence the
document.lastModified value).
Thank you. That reinforces my point that JavaScript lastModified is
only loosely connected to the actual date/time when the last significant
modification was made or uploaded. <js-date2.htm#lM> adjusted.
In short it would depend on the filesystem, the upload method, and the
web server, as to what date is reported. In the common case of using
FTP to upload files the time stamp does change. But rsync, scp,
and other tools can maintain the filesystem's modification timestamp
unless the document was actually modified.
Indeed, 32-bit MiniTrue for Win-32 can edit a local file without
changing the datestamp.
Perhaps the way to deal with minor edits and last modification times
is to use a CMS or similar. Or you can add version numbers to your
documents that don't change for minor edits or re-uploads. (A simple
RCS/CVS/SVN/whatever repository will expand special tokens in
the document source into the current version number.)
Agreed.
It's a shame that the lastModified string was not specified to be an
exact copy of the Last-Modified header, which if RFC-compliant specifies
a time without any ambiguity.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 IE 6.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
I find MiniTrue useful for viewing/searching/altering files, at a DOS prompt;
free, DOS/Win/UNIX, <URL:http://www.idiotsdelight.net/minitrue/> unsupported.
.
- References:
- RFD: How To Recognize Bad Javascript Code
- From: Jeremy J Starcher
- Re: RFD: How To Recognize Bad Javascript Code
- From: Jeremy J Starcher
- RFD: How To Recognize Bad Javascript Code v0.3
- From: Jeremy J Starcher
- Re: RFD: How To Recognize Bad Javascript Code v0.3
- From: Randy Webb
- Re: RFD: How To Recognize Bad Javascript Code v0.3
- From: Dr J R Stockton
- Re: RFD: How To Recognize Bad Javascript Code v0.3
- From: Randy Webb
- Re: RFD: How To Recognize Bad Javascript Code v0.3
- From: Dr J R Stockton
- Re: RFD: How To Recognize Bad Javascript Code v0.3
- From: Wayne
- RFD: How To Recognize Bad Javascript Code
- Prev by Date: Re: Display results in SELECT - Firefox issue
- Next by Date: Displaying a spinner
- Previous by thread: Re: RFD: How To Recognize Bad Javascript Code v0.3
- Next by thread: Re: RFD: How To Recognize Bad Javascript Code v0.3
- Index(es):
Relevant Pages
|