Ignoring withZone in Parsers

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Ignoring withZone in Parsers

John Jenkins
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest

Test.java (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ignoring withZone in Parsers

jodastephen
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 <[hidden email]> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ignoring withZone in Parsers

John Jenkins
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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ignoring withZone in Parsers

John Jenkins
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ignoring withZone in Parsers

jodastephen
Ultimately, there is only one parser being run, the outer one. The
other parts simply help build up the outer parser. So, I suspect that
what you want may not be possible.

For the other parsers, you probably want to call withOffsetParsed(),
as that will correctly read in and create zone information based on
the parsed offset. Even so, I'm not convinced that you could parse all
those formats in a single bound.

Of course, you do have the ability to take more control and implement
DateTimeParser yourself, but that seems a little bit of overkill.

Stephen


On 16 October 2012 17:35, John Jenkins <[hidden email]> wrote:

> 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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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
> [hidden email]
> 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
> [hidden email]
> 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
> [hidden email]
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/joda-interest
>

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
Joda-interest mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ignoring withZone in Parsers

John Jenkins
Thank you. May I suggest that the documentation for the DateTimeFormatterBuilder.append(DateTimePrinter, DateTimeParser[]) be appended with something to the effect of:

"If any of the parsers contain a overriding time zone, that zone will be ignored in the resulting DateTimeFormatter. A DateTimeFormatter has a single overriding time zone, and the parsers provided here will have no bearing on that value."

Even writing that, it feels like a bug, but I am not sure.

In case anyone else comes across this and wants a working solution, I have attached the source that I am going to use. Optimally, I would create IsoW3cDateTimeFormat and IsoW3cDateTimeFormatter classes, but I don't have the time to invest in that right now.

Thanks again,

John




On Oct 16, 2012, at 2:06 PM, Stephen Colebourne <[hidden email]> wrote:

> Ultimately, there is only one parser being run, the outer one. The
> other parts simply help build up the outer parser. So, I suspect that
> what you want may not be possible.
>
> For the other parsers, you probably want to call withOffsetParsed(),
> as that will correctly read in and create zone information based on
> the parsed offset. Even so, I'm not convinced that you could parse all
> those formats in a single bound.
>
> Of course, you do have the ability to take more control and implement
> DateTimeParser yourself, but that seems a little bit of overkill.
>
> Stephen
>
>
> On 16 October 2012 17:35, John Jenkins <[hidden email]> wrote:
>> 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 <[hidden email]> 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 <[hidden email]>
>> 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 <[hidden email]> 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
>> [hidden email]
>> 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
>> [hidden email]
>> 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
>> [hidden email]
>> 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
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/joda-interest
>>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> Joda-interest mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/joda-interest

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
Joda-interest mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest

Test.java (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ignoring withZone in Parsers

John Jenkins
I am not sure if this is a bug or if I am incorrectly implementing the parseInto() function. I cannot chain the parsers and am not sure why.

In ISOW3CDateTimeParser's parseInto() function, if the first three parsers fail, I must reset the bucket in order to check the last three. However, the entirety of the third pattern is the same as the beginning of the forth pattern, so I am not sure why I need to reset.

If this is a bug, then the ISOW3CDateTimeParser and the any() function could be removed. The any() function is a simple wrapper around the ISOW3CDateTimeParser, which is necessary because the parseInto() function is failing.

Also, since the W3C standard is pretty common, I would be thrilled if this were integrated into the code base, but I don't expect it. If so, I can flesh out all of the tests.

Thank you,

John




On Oct 17, 2012, at 11:45 AM, John Jenkins <[hidden email]> wrote:

> Thank you. May I suggest that the documentation for the DateTimeFormatterBuilder.append(DateTimePrinter, DateTimeParser[]) be appended with something to the effect of:
>
> "If any of the parsers contain a overriding time zone, that zone will be ignored in the resulting DateTimeFormatter. A DateTimeFormatter has a single overriding time zone, and the parsers provided here will have no bearing on that value."
>
> Even writing that, it feels like a bug, but I am not sure.
>
> In case anyone else comes across this and wants a working solution, I have attached the source that I am going to use. Optimally, I would create IsoW3cDateTimeFormat and IsoW3cDateTimeFormatter classes, but I don't have the time to invest in that right now.
>
> Thanks again,
>
> John
>
> <Test.java>
>
> On Oct 16, 2012, at 2:06 PM, Stephen Colebourne <[hidden email]> wrote:
>
>> Ultimately, there is only one parser being run, the outer one. The
>> other parts simply help build up the outer parser. So, I suspect that
>> what you want may not be possible.
>>
>> For the other parsers, you probably want to call withOffsetParsed(),
>> as that will correctly read in and create zone information based on
>> the parsed offset. Even so, I'm not convinced that you could parse all
>> those formats in a single bound.
>>
>> Of course, you do have the ability to take more control and implement
>> DateTimeParser yourself, but that seems a little bit of overkill.
>>
>> Stephen
>>
>>
>> On 16 October 2012 17:35, John Jenkins <[hidden email]> wrote:
>>> 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 <[hidden email]> 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 <[hidden email]>
>>> 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 <[hidden email]> 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
>>> [hidden email]
>>> 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
>>> [hidden email]
>>> 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
>>> [hidden email]
>>> 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
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/joda-interest
>>>
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_sfd2d_oct
>> _______________________________________________
>> Joda-interest mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/joda-interest
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct_______________________________________________
> Joda-interest mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/joda-interest

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
Joda-interest mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest

ISOW3CDateTimeFormat.java (11K) Download Attachment
Test.java (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ignoring withZone in Parsers

jodastephen
In reply to this post by John Jenkins
Javadoc clarified.

Its not a bug as the printer and parser interfaces represent just how
the print/parse is to occur, not the formatter-based controls, such as
locale/time-zone.

thanks
Stephen

On 17 October 2012 19:45, John Jenkins <[hidden email]> wrote:

> Thank you. May I suggest that the documentation for the DateTimeFormatterBuilder.append(DateTimePrinter, DateTimeParser[]) be appended with something to the effect of:
>
> "If any of the parsers contain a overriding time zone, that zone will be ignored in the resulting DateTimeFormatter. A DateTimeFormatter has a single overriding time zone, and the parsers provided here will have no bearing on that value."
>
> Even writing that, it feels like a bug, but I am not sure.
>
> In case anyone else comes across this and wants a working solution, I have attached the source that I am going to use. Optimally, I would create IsoW3cDateTimeFormat and IsoW3cDateTimeFormatter classes, but I don't have the time to invest in that right now.
>
> Thanks again,
>
> John
>
>
>
>
> On Oct 16, 2012, at 2:06 PM, Stephen Colebourne <[hidden email]> wrote:
>
>> Ultimately, there is only one parser being run, the outer one. The
>> other parts simply help build up the outer parser. So, I suspect that
>> what you want may not be possible.
>>
>> For the other parsers, you probably want to call withOffsetParsed(),
>> as that will correctly read in and create zone information based on
>> the parsed offset. Even so, I'm not convinced that you could parse all
>> those formats in a single bound.
>>
>> Of course, you do have the ability to take more control and implement
>> DateTimeParser yourself, but that seems a little bit of overkill.
>>
>> Stephen
>>
>>
>> On 16 October 2012 17:35, John Jenkins <[hidden email]> wrote:
>>> 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 <[hidden email]> 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 <[hidden email]>
>>> 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 <[hidden email]> 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
>>> [hidden email]
>>> 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
>>> [hidden email]
>>> 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
>>> [hidden email]
>>> 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
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/joda-interest
>>>
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_sfd2d_oct
>> _______________________________________________
>> Joda-interest mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/joda-interest
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> Joda-interest mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/joda-interest
>

------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Joda-interest mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Loading...