In Cocoon 2.1.7, we are using DirectoryGenerator
(http://cocoon.apache.org/2.1/userdocs/directory-generator.html) and
using the lastModified time of each file to color-code the files by age.
But we've been seeing very strange behavior, and it boils down to the
fact that the last-modified-time represented by @date and by
@lastModifiedTime are actually different times!
For example, @date will say the file was modified 11/20/08 9:34 AM
(which happens to be local time and is correct), but @lastModifiedTime
says 1227195241811. If you translate that from
milliseconds-since-the-epoch into a human-readable date, you get
2008-11-19T23:19:09!
You might say "time zone mistake" but note that the minutes are not even
the same! Also, I am 6 hours away from GMT but the difference between
those two times is about 10 hours!
Here was my XSLT code to translate @lastModified into a human-readable
string:
<xsl:variable name="last-mod-time-from-msec"
select="xs:dateTime('1970-01-01T00:00:00')
+ (xs:integer(@lastModified) * xs:dayTimeDuration('PT0.001S'))"/>
(Thanks to
http://www.stylusstudio.com/ssdn/default.asp?boardid=1&action=9&read=5622&fid=48
for a succinct way to do this!)
Then I just convert it the result to a string as in
<span title="...{$last-mod-time-from-msec}..."> and get
2008-11-19T23:19:09.352.
Is/was this a known bug in Cocoon? Does it matter that I'm running
Cocoon under Tomcat on Windows 2000 Server?
I guess we can just use @date instead of @lastModified, and parse it
into a dateTime data type before doing operations on it; but that
defeats the purpose of having lastModified as an integer.
Thanks,
Lars
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
