(Sorry I can't directly 'reply' to Grzegorz' message... I don't seem to be receiving the emails even though I'm subscribed.)
> Lars Huttar pisze: > >> 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. > > This is a code responsible for adding both attributes: > > attributes.addAttribute("", LASTMOD_ATTR_NAME, LASTMOD_ATTR_NAME, "CDATA", > Long.toString(path.lastModified())); attributes.addAttribute("", > DATE_ATTR_NAME, DATE_ATTR_NAME, "CDATA", dateFormatter.format(new > Date(lastModified))); > > It looks simple and just fine so if I were you I would have a closer look at > your conversion method. > > -- Grzegorz Kossakowski Thanks for looking at this. I checked my results another way as follows. I obtained the current time via an XSP page: <xsp:page language="java" xmlns:xsp="http://apache.org/xsp";> <xsp:logic> // Define a variable to hold the time of day Date now = new Date(); </xsp:logic> <current-time title="Current time, in milliseconds since the Epoch"> <xsp:attribute name="asString"><xsp:expr>now.toString()</xsp:expr></xsp:attribute> <xsp:expr>now.getTime()</xsp:expr> </current-time> </xsp:page> And I would get, e.g. <current-time title="Current time, in milliseconds since the Epoch" asString="Thu Nov 20 16:04:28 CST 2008">1227218668398</current-time> and I verified that the asString value there was correct. I then subtracted @lastModified from the current-time number, and divided by (3600*1000) to get age in hours. As above, the age was off by about 10 hours. Since both methods are giving the same result, I figure that the @lastModified value really is wrong. But I see what you mean about the code. It sure looks like the @date attribute's value is just a formatted version of the same value as @lastModified... and as noted above, the @date value is coming through correctly. So... I'm confused. Something's not adding up somewhere. Maybe date.toString() and dateFormatter.format(date) are giving wildly different results... but it seems implausible that they would disagree not just by 6 hours (distance from local time to GMT) but by 10 hours give-or-take an odd number of minutes. Thanks for any further suggestions, Lars --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
