We're just talking about the format, not the actual date, so there's
no timezone information. For example, I might put in my preferences a
format of %d/%m/%y, but the Datepicker is looking for something like
dd/mm/yy. I realized that we use date_format in a whole bunch of
places, so the only realistic option is to translate on the fly. My
latest jQuery branch commits include this translation, so I think we
can move forward on merging to trunk.
On Nov 3, 2009, at 6:53 AM, Reinier Balt wrote:
Does the conversion take the users timezone into account? In that
case we could convert to UTC in the db and feed it into the right
timezone and format into the new datepicker?
Reinier
Van: [email protected] [mailto:tracks-
[email protected]] Namens Eric Allen
Verzonden: vrijdag 30 oktober 2009 20:26
Aan: track-discuss
Onderwerp: [Tracks-discuss] Merging to trunk: one last issue
Hey Tracks community,
I'm finally ready to merge my jQuery brach back into the mainline
Tracks trunk, but I have one little issue. Our old datepicker used
the strftime() standard format with percents and stuff. jQuery UI's
Datepicker, well, doesn't. How should we deal with the switch?
Should I write a simple migration that just transforms month, day,
and year symbols? I'm concerned that I won't get it quite right and
I'll break somebody's Tracks instance. Do we leave the old format
and translate on the fly? That seems like the worst of both worlds
to me. Do we just reset everybody's format and put something in the
changelog telling people to update their date formats? What do you
think would be the best way to handle the transition to the jQuery
UI Datepicker's date format string?
-Eric
_______________________________________________
Tracks-discuss mailing list
[email protected]
http://lists.rousette.org.uk/mailman/listinfo/tracks-discuss
