Hmmm. Im not sure. This wasnt working for me in dev or production. And the
timestamps are there in both environments.You are right about what theyre
meant for though. I read about it here

Its explained a bit more in detail in the API under the Using Asset
Timestamps section

"This allows you to set a cache-expiration date for the asset far into the
future, but still be able to instantly invalidate it by simply updating the

I updated my JS files in my project in dev but it dint work. Everything
following that line in the API, goes right over my head. He's talking about
setting a future cache expiration time.. dont quite grasp that.

On Mon, Apr 27, 2009 at 7:41 PM, Walter Lee Davis <>wrote:

> Hmmm. Well, that's odd, but chalk one up to Rails and its development/
> test/production "environments". The querystring at the end of the
> filename is there to "force" the browser to get a newer version of the
> script. That number is the current time in Unix time() mode, I think,
> or it may be keyed to the migration timestamp, I can't recall. In
> production mode, I don't think you see that -- so the browser is
> encouraged to cache the script for better performance. Maybe your code
> was stuck on a cached version with an error in it -- an error you
> subsequently fixed.
> Walter
> On Apr 27, 2009, at 9:38 AM, Vinay Seshadri wrote:
> > Im so sorry to have put you through all that only for it to end up
> > being something so silly!!
> > Im going to see if anyone else has discussed such behaviour before
> > anywhere online. If not, gonna start a thread in a Rails forum to
> > see what others think about it.
> >

In Sport We Trust !!!

You received this message because you are subscribed to the Google Groups 
"Prototype &" group.
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at

Reply via email to