From the Application.java in my project template for all new projects

static {
        // Set default time zones
        TimeZone.setDefault(TimeZone.getTimeZone("GMT"));
        NSTimeZone.setDefaultTimeZone(NSTimeZone.getGMT());
}


And the timezone detector works for me. It's in my project template's 
PageWrapper. 

Keep in mind, that just because you have collected the time zone doesn't mean 
it is being used anywhere. If you include the property

er.extensions.ERXSession.autoAdjustTimeZone=true

Then WOTextFields and WOStrings with a dateFormat binding will automatically 
adjust the time zone based on your ERXSession.timeZone(). 

Otherwise, you must handle the time zone adjustments in the interface yourself. 
This includes using a formatter binding. 

If you're using R2D2W, then this is also automatically handled by rules that 
produce formatObject. That in turn is used as the formatter for all my property 
level components. Example:

10 : ((smartAttribute.valueFactoryMethod != null and 
smartAttribute.factoryMethodArgumentType = 3) and smartAttribute.className = 
'org.joda.time.DateTime') => formatObject = {"arguments" = ({"className" = 
"java.lang.String"; "contextKey" = "formatter"; }, {"className" = 
"java.util.Locale"; "contextKey" = "session.localizer.@locale"; }, {"className" 
= "java.util.TimeZone"; "contextKey" = "session.timeZone"; }); "className" = 
"er.extensions.formatters.ERXJodaDateTimeFormatter"; } 
[ERDDelayedObjectCreationAssignment]



On Jul 9, 2013, at 7:47 AM, Jesse Tayler wrote:

> oh? thanks Ken.
> 
> that’s interesting.
> 
> when I put those in, the Ramsey widget won’t work and I can’t reset them!
> 
> when I take them out, things return to ‘normal’ but then I wonder why I had 
> them in the first place?
> 
> I think it might have been that ERRest had trouble?
> 
> Are you both Web and ERRest on these sites you have?
> 
> Got any clues about what’s going on?
> 
> My database knows it is to be GMT, and a quick test of the new web stuff 
> suggests that it’s ok — but I should run more tests maybe.
> 
> 
> On Jul 9, 2013, at 8:26 AM, Ken Anderson <[email protected]> wrote:
> 
>> Every app I have makes similar default calls.
>> 
>> On Jul 8, 2013, at 8:34 PM, Paul Hoadley <[email protected]> wrote:
>> 
>>> On 09/07/2013, at 3:29 AM, Jesse Tayler <[email protected]> wrote:
>>> 
>>>> I realize I had apparently statically set the timezone to GMT?
>>>> 
>>>> Maybe I did this for my database??
>>>> 
>>>> I had this in my app constructor
>>>> 
>>>>    static {
>>>>            // Set default time zones
>>>>            //TimeZone.setDefault(TimeZone.getTimeZone("GMT"));
>>>>            //NSTimeZone.setDefaultTimeZone(NSTimeZone.getGMT());
>>>>    }
>>>> 
>>>> once I noticed those two line and commented them out, general <wo:str>’s 
>>>> zapped into a correct timezone on display - my component is another story 
>>>> but--
>>>> 
>>>> now I wonder if I’ll be storing my dates differently in the database?
>>> 
>>> In my experience, you almost certainly want to leave those setDefault calls 
>>> _in_.  The only failsafe way to deal with timezones is to set UTC 
>>> everywhere except the view layer.  So, yes, you want to ensure your 
>>> database is storing timestamps as UTC (and not doing any "helpful" timezone 
>>> conversions on the way in or out), the JVM's default is UTC, and WebObjects 
>>> default is UTC.  The only time you do a conversion is on the way in from 
>>> the view, or on the way out to the view, both using a user-selected or 
>>> automatically-detected timezone offset.
>>> 
>>> 
>>> -- 
>>> Paul Hoadley
>>> http://logicsquad.net/
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list      ([email protected])
>>> Help/Unsubscribe/Update your Subscription:
>>> https://lists.apple.com/mailman/options/webobjects-dev/kenlists%40anderhome.com
>>> 
>>> This email sent to [email protected]
> 
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list      ([email protected])
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/webobjects-dev/rgurley%40smarthealth.com
> 
> This email sent to [email protected]


 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      ([email protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to [email protected]

Reply via email to