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

["J.H." <warthog9@eaglescrag.net>]

On 03/24/2011 03:00 PM, Kevin Cernekee wrote:
> 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)

>> 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