Re: ReSpec bug: generated date uses GMT rather than Locale time

Hi James,

On 29/11/2012 01:35 , James Craig wrote:
> Minor bug to report:  Just noticed the draft I'm editing lists
> tomorrow's date (Nov 29) which is accurate for GMT at the moment, but
> not for me in the US Pacific time zone (4:30pm on Nov 28). Probably
> just needs a toDateString method replaced with toLocaleDateString.

Maybe, maybe not :)

There are essentially two ways in which that date comes to be. The first 
one is through explicit setting by the editor (using publishDate). In 
that case, I really don't want to touch it in any way: if the editor 
says that's the date to use, then it's the date to use. That case is for 
release snapshots, so it is often a date several days in the future.

The other case is when no date has been explicitly set, ReSpec falls 
back to document.lastModified. In this case, I could indeed probably 
parse it and try to make it match whatever the local user has. But I'm 
reluctant to do so because — believe it or not — browsers vary somewhat 
on what they return for document.lastModified. That could be handled, 
but then you have the problem that servers regularly return the wrong 
information for that, too. And they tend to be wrong in all sorts of 
creative ways, from the clock being off to the TZ being wrong, including 
always returning the time of the request as the last modification time 
(which dvcs.w3 does for instance).

At the end of the day it's just not very reliable information. I include 
document.lastModified as a fallback because otherwise editors are 
tempted to set publishDate manually, then forget to change it when they 
make edits, which in turn causes people to think that they're looking at 
an outdated ED.

So by falling back to document.lastModified we get a sense that the 
draft was updated "recently", albeit one that you really wouldn't want 
to set your watch by.

> Is the list the right place to file bugs? Thanks. — James

It is. You can also use https://github.com/darobin/respec/issues.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Monday, 3 December 2012 12:21:02 UTC