Re: [PATCH 1/1] gitweb: javascript ability to adjust time based on timezone

From: J.H. <warthog9@eaglescrag.net>
Date: Mar 24, 2011, 22:29 UTC
Message-ID: <4D8BC5C3.4010309@eaglescrag.net>
In-Reply-To: <AANLkTi=OsPwQxMRoxLSUEXE1FzSYNvrv3Y+-rXUbzTST@mail.gmail.com>

On 03/24/2011 03:00 PM, Kevin Cernekee wrote:

Show 18 quoted lines

> 2011/3/24 Jakub Narebski <jnareb@gmail.com>:
>>> 4) IE6 does not seem to like ISO 8601 format:
>>>
>>> x = new Date("2011-03-09T03:29:09Z");
>>>
>>> This sets all fields to NaN.  I suspect that getTime() values
>>> (milliseconds since 1970-01-01) are more portable.
>>
>> Do you mean using epoch in title attribute, or fallback to parsing
>> ISO 8601 UTC format with regexps?
> 
> getTime() format is $epoch * 1000.  When I switched to that format,
> all 3 of my browsers were able to handle it.
> 
> I really don't think relying on "new Date(iso8601_timestamp)" is a
> good idea, but I guess the string parsing approach would work:
> 
> http://webcloud.se/log/JavaScript-and-ISO-8601/

Looking at that, MS provides VM images for compatability testing with older IEs so I'm at least able to see the problem directly. There's also badness in using epoch directly, screen readers will handle that particularly badly (which is one of the reasons the microformats generally shifted to a slightly, if more painful to read from Javascript, method)

Show 12 quoted lines

>> Dealing with DST (zoneinfo library) is simply too hard for JavaScript
>> IMHO.  What we could do is to store "local" in cookie, not a fixed TZ
>> offset (or perhaps store both as to not recalculate it).
> 
> I agree, and I do not have a comprehensive solution for handling
> non-local timezones.
> 
>> Hmmm... perhaps a 'config' page?
> 
> Any thoughts on what other user-configurable items might get added in
> the future, and whether they will be on the client side or server
> side?

Any configurations that would happen there will all be client side, for a lot of reasons gitweb will not be able to have anything user level configurable from the server side (well at least any of the larger gitweb installs, which is what I'm primarily focused on). That said there's a lot we could do with Javascript from the client side, and that was one way of handling to change I had thought of - just didn't seem useful since we currently would only have this.

I'm fine with the idea however (I envisioned it as some larger drop down that more or less filled the whole page and set various cookies for it's storage of things). But moving in this direction should be a conscious and definitive move that these kinds of changes will be client side, and will involve more and more Javascript. Assuming that our fallback non-javascript version of the page still works fine, and is usable, this is a good plan overall but it is a shift from where we have been with respect to Gitweb.

- John 'Warthog9' Hawley