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

Gracefully handle long time intervals #2354

Merged
merged 3 commits into from
May 2, 2018
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 7 additions & 1 deletion lib/iris/coords.py
Original file line number Diff line number Diff line change
Expand Up @@ -732,7 +732,13 @@ def __str__(self):
fmt = '{cls}({points}{bounds}' \
', standard_name={self.standard_name!r}' \
', calendar={self.units.calendar!r}{other_metadata})'
points = self._str_dates(self.points)
if self.units.is_long_time_interval():
Copy link
Member

Choose a reason for hiding this comment

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

This makes Iris have a hard dependency on cf_units >= 1.2. We need to update the requirements to reflect that (or not have such a hard dependency)

# A time unit with a long time interval ("months" or "years")
# cannot be converted to a date using `num2date` so gracefully
# fall back to printing points as numbers, not datetimes.
points = self.points
else:
points = self._str_dates(self.points)
bounds = ''
if self.has_bounds():
bounds = ', bounds=' + self._str_dates(self.bounds)
Expand Down
27 changes: 26 additions & 1 deletion lib/iris/tests/unit/coords/test_Coord.py
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
# (C) British Crown Copyright 2013 - 2017, Met Office
# (C) British Crown Copyright 2013 - 2018, Met Office
#
# This file is part of Iris.
#
Expand Down Expand Up @@ -323,5 +323,30 @@ def test_convert_unknown_units(self):
with self.assertRaisesRegexp(UnitConversionError, emsg):
coord.convert_units('degrees')


class Test___str__(tests.IrisTest):

def test_short_time_interval(self):
coord = DimCoord([5], standard_name='time',
units='days since 1970-01-01')
expected = ("DimCoord([1970-01-06 00:00:00], standard_name='time', "
"calendar='gregorian')")
result = coord.__str__()
Copy link
Member

Choose a reason for hiding this comment

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

Out of interest - why not use the built-in str?

Copy link
Member Author

Choose a reason for hiding this comment

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

To catch up an offline conversation – the reason is that in this test class I'm testing the literal coord.__str__ implementation. While this and str are of course behaviourally identical, using __str__ here seemed a more explicit statement of intent than using str.

self.assertEqual(expected, result)

def test_long_time_interval(self):
coord = DimCoord([5], standard_name='time',
units='years since 1970-01-01')
expected = "DimCoord([5], standard_name='time', calendar='gregorian')"
result = coord.__str__()
self.assertEqual(expected, result)

def test_non_time_unit(self):
coord = DimCoord([1.])
expected = repr(coord)
result = coord.__str__()
self.assertEqual(expected, result)


if __name__ == '__main__':
tests.main()
2 changes: 1 addition & 1 deletion requirements/core.txt
Original file line number Diff line number Diff line change
Expand Up @@ -9,5 +9,5 @@ netcdf4
numpy
scipy
# pyke (not pip installable) #conda: pyke
cf_units
cf_units>=1.2
dask>=0.17.1