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

layer endDate is parsed incorrectly during build #1033

Closed
ZachTRice opened this issue Jun 1, 2018 · 0 comments
Closed

layer endDate is parsed incorrectly during build #1033

ZachTRice opened this issue Jun 1, 2018 · 0 comments
Assignees

Comments

@ZachTRice
Copy link
Contributor

Description

The layer endDate is parsed incorrectly. If you inspect a layer like black marble; 2016-01-01 from GC gets transformed into 2017-01-01T00:00:00Z instead of 2016-01-01T00:00:00Z.

The layer startDate work as intended.

Another example: SWDB_Aerosol_Optical_Thickness_550nm_Monthly

<Value>1997-10-01/2008-01-01/P1M</Value>
<Value>2008-04-01/2008-06-01/P1M</Value>
<Value>2008-08-01/2009-04-01/P1M</Value>
<Value>2009-06-01/2009-08-01/P1M</Value>
<Value>2009-11-01/2010-12-01/P1M</Value>

Expected behavior:
startDate should equal: 1997-10-01T00:00:00Z
endDate should equal: 2010-12-01T00:00:00Z

Actual behavior:
startDate actually equals: 1997-10-01T00:00:00Z (correct)
endDate actually equals: 2011-01-01T00:00:00Z (incorrect)

Note: Looks like end_date = determine_end_date(times[2], end_date) is the likely cause since this bug only affects monthly and yearly layers and we have the following in processTemporalLayer.py:

if times[2] != "P1D":
                    end_date = determine_end_date(times[2], end_date)

determine_end_date does an additional isodate parse

Environment

Version: 2.2.0+
Browser: all

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants