Does anybody have experience detecting such a condition, perhaps through one
of the client headers? I haven't had a chance to dump them - many hats.
In any case, I could use some Javascript to package up the machine's current
time and send it back to the server, for instance at the same point where I
check whether a cookie was accepted. That'd indicate their
"Javscript-OK"-ness too. I think I'm willing to assume that someone clueful
enough to turn off Javascript is clueful enough to have the correct time.
Any other offers as to a cleaner solution?
Randy
On Fri, Jan 07, 2000 at 09:52:25AM +0000, G.W. Haywood wrote:
> Hi there,
>
> On Fri, 7 Jan 2000, Randy Harmon wrote:
>
> > Currently, I'm experiencing the problem with Netscape 4.7, although I seem
> > to recall the same problem in earlier releases, in the case where the target
> > browser's clock is slow.
> >
> > [snip] can be corrected by explicitly setting an Expires header that's in
> > the past. How far in the past depends on how lenient you wish to be with
> > browsers with slow clocks.
> >
> > Something between 5 and 30 minutes seems reasonable to me, but discussion
> > may demonstrate a different approach and/or timeframe.
> >
> > Thoughts?
>
> Well, quite a lot of computers now fire up with the clock saying some
> time around 4 Jan 1980. Just how far do you let this go? My view is
> that if he suspects that it may cause a problem, one should tell his
> user to make sure the clock is right. Caveat browsor. I feel sure
> that deliberately lying about the time is a dangerous path to tread.
> Of course we can't (yet) expect everyone to be running ntpd, and five
> minutes doesn't initially seem unreasonable, but we could then expect
> biennial fun and games when daylight savings time kicks in and out, or
> not, as the case often may be. The software industry has a bad enough
> reputation as it is, without yet another kind of periodic Y2k bug.
>
> Maybe a Request For Comment?
>
> Or a word in someone's ear at the browser development labs?
>
> 73
> Ged.
>
