Sorry to pry, but I think you may have missed my follow-up question.
With your solution, the resulting DateTime object loses its time zone, but the
last 3 parsers attempt to preserve that information. I only need it to default
to UTC for the first three. Is there a way to modify only those parsers, not
the entire DateTimeFormatter, to have them default to UTC instead of the local
time?
Thank you,
John
On Oct 11, 2012, at 9:37 AM, John Jenkins <joje...@cens.ucla.edu> wrote:
> Thank you. That line was not intended to be sent, but your solution will work
> for me for the time being.
>
> However, the larger problem that I am going to face with this solution is
> that the timezone information is lost. If they give me one of the first three
> formats then the timezone defaults to UTC, which is what your fix does. But,
> if they give me any of the last three timezones, I need to preserve the
> timezone. That is why I was trying to add the "withZoneUTC()" to the
> individual parsers and not the larger formatter.
>
> Then, my formatter would probably be:
> DateTimeFormatterBuilder builder = new DateTimeFormatterBuilder();
> builder.append(ISODateTimeFormat.dateTime().getPrinter(), parsers);
> ISO_W3C_DATE_TIME_FORMATTER = builder.toFormatter();
>
> Thank you,
>
> John
>
> On Oct 11, 2012, at 3:25 AM, Stephen Colebourne <scolebou...@joda.org> wrote:
>
>> You wrote:
>> ISO_W3C_DATE_TIME_FORMATTER = builder.toFormatter();
>> ISO_W3C_DATE_TIME_FORMATTER.withZoneUTC();
>>
>> The second line has no effect, because the formatter is immutable, and
>> you do not assign back the variable.
>>
>> This will work:
>> ISO_W3C_DATE_TIME_FORMATTER = builder.toFormatter().withZoneUTC();
>>
>> Your code is also similar to
>> http://joda-time.sourceforge.net/api-release/org/joda/time/format/ISODateTimeFormat.html#localDateOptionalTimeParser%28%29
>>
>> Stephen
>>
>>
>> On 11 October 2012 00:04, John Jenkins <joje...@cens.ucla.edu> wrote:
>>> I apologize if this has been answered / justified elsewhere, but I could not
>>> find it.
>>>
>>> I am creating a parser based on the ISO year-month-day parser. I want to set
>>> the default timezone of the returned object to UTC, but it is instead
>>> defaulting to my local timezone. The code looks like this:
>>>
>>> ISODateTimeFormat.yearMonthDay().withZoneUTC().getParser();
>>>
>>> The only pseduo-reasoning I have found was in the documentation:
>>>
>>> This will parse the text fully according to the formatter, using the UTC
>>> zone. Once parsed, only the local date-time will be used. This means that
>>> any parsed time-zone or offset field is completely ignored. It also means
>>> that the zone and offset-parsed settings are ignored.
>>>
>>> What I expect to happen is that the string "2012-08-15" be decoded to a time
>>> that represents midnight on August 15th, 2012 at UTC. Instead, I get that
>>> date and time but at my local timezone, e.g.
>>> "2012-08-15T00:00:00.000-07:00".
>>>
>>> I am just curious why this is. A colleague and I discussed it. The answer he
>>> came up with is, because only a date is supplied, the time zone doesn't
>>> matter. However, I would argue that, at 23:00 PM on December 31 it would
>>> very much matter. The year, month, and day can all vary depending where you
>>> are in the world, so all three values may be different. But, they do
>>> represent the same moment in time. This can only be determined if the
>>> timezone is also included.
>>>
>>> I attached the complete source, but I don't know if that will be preserved.
>>>
>>> Thank you,
>>>
>>> John
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Don't let slow site performance ruin your business. Deploy New Relic APM
>>> Deploy New Relic app performance management and know exactly
>>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>>> http://p.sf.net/sfu/newrelic-dev2dev
>>> _______________________________________________
>>> Joda-interest mailing list
>>> Joda-interest@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/joda-interest
>>>
>>
>> ------------------------------------------------------------------------------
>> Don't let slow site performance ruin your business. Deploy New Relic APM
>> Deploy New Relic app performance management and know exactly
>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>> http://p.sf.net/sfu/newrelic-dev2dev
>> _______________________________________________
>> Joda-interest mailing list
>> Joda-interest@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/joda-interest
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev_______________________________________________
> Joda-interest mailing list
> Joda-interest@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/joda-interest
------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
Joda-interest mailing list
Joda-interest@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/joda-interest
