W3C home > Mailing lists > Public > spec-prod@w3.org > October to December 2012

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

From: James Craig <jcraig@apple.com>
Date: Mon, 03 Dec 2012 08:15:12 -0800
Cc: spec-prod@w3.org
Message-id: <2E583932-5D5D-4E3F-A123-B10FEE0568D2@apple.com>
To: Robin Berjon <robin@w3.org>
Fair enough. 

If you'd like, I can file an issue where you can document this behavior and the reason it's "Not to be Fixed." That'll give you a link to use next time someone asks this question.

On Dec 3, 2012, at 4:20 AM, Robin Berjon <robin@w3.org> wrote:

> 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 16:15:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:55:17 UTC