Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow for negative unix timestamps #11482

Merged
merged 1 commit into from
Jun 22, 2015

Conversation

spinscale
Copy link
Contributor

This fixes an issue to allow for negative unix timestamps.
It also fixes the default date field mapper to support epochs.

Fixes #11478
Fixes #11692

@spinscale
Copy link
Contributor Author

One thing to discuss is, if it makes sense to check for the length of the epoch timestamps. Right now they are limited to 10/13 chars depending on millisecond resolution, which means the max date is 2286. Maybe we should just loosen this?

@rmuir
Copy link
Contributor

rmuir commented Jun 3, 2015

Right now they are limited to 10/13 chars depending on millisecond resolution, which means the max date is 2286. Maybe we should just loosen this?

If someone is using our 200 years from now, then they have larger problems.

@spinscale
Copy link
Contributor Author

I was more thinking about different worlds... like in games. however then one potentially should just use ISO8601 dates and not unix timestamps :)

@nik9000
Copy link
Member

nik9000 commented Jun 3, 2015

just use ISO8601 dates

+1

Probably worth documenting the way it works if it isn't already but "just use ISO8601" is almost never bad advice.

@rmuir
Copy link
Contributor

rmuir commented Jun 3, 2015

I actually disagree with that. ISO8601 is overly complex.

RFC3339 is good enough and much simpler. Exotic use cases that don't work with it could be handled by a separate complicated ISO8601 plugin :)

@spinscale
Copy link
Contributor Author

agreed, lets replace iso8601 with rfc3339 in my sentence above... I think it's ok to keep the validity checks. Will update the docs as part of this PR as well

@spinscale spinscale force-pushed the 1506-issue-11478-fix-mapping branch from 9453039 to 2e221f9 Compare June 4, 2015 13:01
@spinscale
Copy link
Contributor Author

updated docs to reflect the ability to only go up/down to a certain year with a unix timestamp, also added bwc documentation

@clintongormley clintongormley changed the title Dates: Allow for negative unix timestamps Allow for negative unix timestamps Jun 8, 2015
} else if ("epoch_millis".equals(input)) {
formatter = new DateTimeFormatterBuilder().append(new EpochTimeParser(true)).toFormatter();
formatter = new DateTimeFormatterBuilder().append(forPattern("dateOptionalTime").printer().getPrinter(), new EpochTimeParser(true)).toFormatter();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it seems wrong to me to give the dateOptionTime printer to the epoch_* formats, since in that case I would not be able to print epoch dates if I needed/wanted to? I would suggest allowing these formats to print as epoch timestamps and then the user can use the order of formats in the format field to determine how they want the date to be printed.

Maybe also (in a different PR) we should separate index and display time formats into different options so you could set only e.g. epoch_second to be allowed when indexing documents but display a more human readable format to the user at query time?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 on a dedicated printer

Maybe also (in a different PR) we should separate index and display time formats into different options so you could set only e.g. epoch_second to be allowed when indexing documents but display a more human readable format to the user at query time?

One thing that makes me uncomfortable about this is that it means that a format could not always parse the dates that it prints.

@spinscale spinscale force-pushed the 1506-issue-11478-fix-mapping branch from 2e221f9 to eee5550 Compare June 17, 2015 15:27
@spinscale
Copy link
Contributor Author

added an EpochPrinter here as well... @jpountz maybe you can have a look if that helps your case, I will check if I can optimize the code a bit more instead of reading out the fields piece by piece, maybe the timestamp already exist and I can just reuse it

if (hasMilliSecondPrecision) {
out.write(String.valueOf(instant));
} else {
out.append(String.valueOf(instant * 1000));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldn't it be /1000 instead?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed and test added

@spinscale spinscale force-pushed the 1506-issue-11478-fix-mapping branch from eee5550 to ae15808 Compare June 22, 2015 07:24
}

public void testThatEpochParserIsIdempotent() {
FormatDateTimeFormatter formatter = Joda.forPattern("epoch_millis");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no tests for epoch_second?

@jpountz
Copy link
Contributor

jpountz commented Jun 22, 2015

LGTM

This fixes an issue to allow for negative unix timestamps.
An own printer for epochs instead of just having a parser has been added.
Added docs that only 10/13 length unix timestamps are supported
Added docs in upgrade documentation

Fixes elastic#11478
@spinscale spinscale force-pushed the 1506-issue-11478-fix-mapping branch from ae15808 to 38ddc81 Compare June 22, 2015 09:57
@spinscale spinscale merged commit 38ddc81 into elastic:master Jun 22, 2015
@kevinkluge kevinkluge removed the review label Jun 22, 2015
s1monw added a commit that referenced this pull request Jun 22, 2015
@clintongormley clintongormley added the :Search Foundations/Mapping Index mappings, including merging and defining field types label Feb 13, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>enhancement :Search Foundations/Mapping Index mappings, including merging and defining field types v2.0.0-beta1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Histogram Agg result fails to generate XContent Date parsing: Ensure parsing negative unix timestamps works
7 participants