You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Lars Huttar <la...@sil.org> on 2008/11/21 00:10:24 UTC

lastModified value is wrong in DirectoryGenerator

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

Re: lastModified value is wrong in DirectoryGenerator

Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org