Re: lastModified value is wrong in DirectoryGeneratorLink to this message

[Lars Huttar <la...@sil.org>]

(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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org