TimeZones! TimeZones suck!
Working on a project that's deployed on GAE. GAE only works on UTC. That's the default TimeZone, and everything done within the running image is done at UTC. Specifically, Date parsing and display default to UTC. This is not so good when you're doing a local app, in my case PST/PDT. I chatted with the gang on IRC about ways around this and how to work with it. Through various attempts I settled on using a custom TypeConverter and Formatter for dates hard code to my time zone. (I'll pause while Ben mops up whatever beverage he has just spewed over his expensive computer equipment and his antique mahogany desk overlooking the tranquil rustic harbor from his hillside, panoramic window). The change was simple, but it brought up other issues. Basically, this technique works great, if you're limited to a single time zone. But not so much if you want a flexible time zone (like say a user setting). The problem centers around the fact that the TypeConverters and Formatters have no context whatsoever. They have no access to the StripesContext or the Session or anything else. The <s:text > tag also has no way to specify a time zone, and the Formatters have no way to have a TZ passed to them even if we added a parameter to s:text. Also, the TZ on s:text would only affect rendering, not parsing, so it's inelegant at best anyway. So, simply, I'd like to suggest in Stripes 2.0 that the formatters and type converters be given some kind of access to the current request. Then they can leverage the Session or some other piece of information tied to the request itself. We can hack around this currently with something like a ThreadLocal, but that's something I think is kind of distasteful. I suggest it for S2.0 simply because I don't think it could be done without breaking all of the current TCs and Formatters, and that shouldn't be done in a 1.x release. A touch rude. We could maintain the "old" TCs and Formatters and create an "extended" TC and Formatter and dispatch internally, but that's kind of nasty in a "these have been deprecated forever why are they still here" kind of way. But that's a different discussion. I guess we could instead add a "WantsContext" interface and if we see that, then call a setContext method on the TC/Formatter. That way new TCs can broadcast that they want it, and old TCs work just peachy. Perhaps that's not so nasty bad that we could do that right now (I haven't looked at how much of the StripesContext is available at this phase of the processing, I'm just blindly assuming it's handy). Anyway, fuel for the fire. Share and Enjoy! Regards, Will Hartung ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
