On 5/8/2013 9:29 AM, Eric Jain wrote:
On Wed, May 8, 2013 at 5:37 AM, Marcin Dojwa m.dojwa@livechatinc.com wrote:
Thanks for this one. What happens if you give '2012-11-30T15:00:00Z'? The
given datetime is treated as UTC or default timezone too ?
If your local timezone offset is e.g. -07:00, doc['timestamp'].date is
now (0.90) '2012-11-30T08:00:00-07:00'. Previously (0.20), it would
have been '2012-11-30T15:00:00Z'; not because elasticsearch was
honoring the date's original timezone offset (I wish it did!), but
because the date property in a script would be always be UTC.
Actually both of those are the same millisecond value stored in the date
field displayed differently (In the Summer 8 AM in Seattle is the same
moment in time as 3 PM in London) Therefore, it depends on the
definition of what the script aDateField.date is supposed to correspond
to in the Joda date library and thus what toString method is used to
convert the results back to the caller. It is not a matter of honoring
the original TZ, because it can't, the field stores a millisecond value;
that's it. On the way out nothing knows how it got that millisecond
value into the field.
As Eric as observed
it WAS converting the millisecond value to the result string using UTC.
but now
it IS converting to the millisecond value to the result string using the
DEFAULT VM timezone.
"The default date parsing used if no format is specified is
ISODateTimeFormat.dateOptionalTimeParser
http://joda-time.sourceforge.net/api-release/org/joda/time/format/ISODateTimeFormat.html#dateOptionalTimeParser()."
"... The first format will also act as the one that converts back from
milliseconds to a string representation. ..."
-- Elasticsearch Platform — Find real-time answers at scale | Elastic
None of the formats specified make any claim as to what TZ will be used
when formatting the millisecond value into a readable string, but
certainly being able to pick one by setting default VM timezone is a
valid choice, but so is the earlier idea of always using UTC, so I don't
know which behavior is intended. It is also important that all output
formats do the same thing and not mix VM default with UTC. One idea is
that forcing UTC as the default on the way out reminds folks to think
about what they want to see and to learn the difference between how it
is stored and how it is transported back (hopefully it is short leap of
logic to thinking about how it is transported into the index).
Just as a warning to all, having client and server us different
timezones can make hard to find bugs when using the default input format
which allows dates (without times) sent from clients generating local
dates and then falling into the previous or next day, because they end
up at "somebody else's" (the servers) midnight when it is converted for
storage into a millisecond value.
Client says "2013-05-10" (thinking that means "2012-05-10 T 00:00:00
-07:00" or "2012-05-10 T 07:00:00Z"), server records a timestamp of 7
hours earlier "2012-05-10 T 00:00:00 Z". If later the client code
fully specifies things with times and timezones, things can be curiously
mismatched with the original timestamp and get subtly confusing.
-Paul
--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.