Aligns with XSD, exists in SQL.
I added duration to my usage of JTS, but I'd prefer not to deviate from the spec.
@back5576 could you share an example of how you implemented it?
For spec here:
I named the new datatype "duration" and values are in days.
It's not a spec but we should probably have something that behave like Python Pandas to_timedelta
Python 3.4.3 |Anaconda 2.3.0 (x86_64)| (default, Mar 6 2015, 12:07:41)
Type "copyright", "credits" or "license" for more information.
IPython 4.0.0 -- An enhanced Interactive Python.
? -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help -> Python's own help system.
object? -> Details about 'object', use 'object??' for extra details.
In : import pandas as pd
In : pd.to_timedelta("0 days 01:03:30.24")
Out: Timedelta('0 days 01:03:30.240000')
The problem with this is that we can't use weeks, months, years.
It seems that they are using internally nanoseconds
In : pd.to_timedelta(1E9)
Out: Timedelta('0 days 00:00:01')
ISO 8601 also defines a period (duration)
I seems to be used in XML Schema
and that's probably better to follow this way
We needed a period type in an application visualizing statistical output tables. Actually many if not most statistical output tables contain periods as they concern quarters, months, years. For visualizing we wanted to differentiate between periodical figures belonging to one specific date (e.g. population the January 1) or belonging to a period (e.g. inflation). We decided to use the regular date field allowing also the ISO 8601 period specifier referenced by @femtotrader. The first quarter of 2015 can then be represented using 2015-01/P3M; the first month by 2015-01 or 2015-01/P1M; the complete year 2015 by 2015 or 2015/P1Y.
What I call a period above is a period between two specific dates. It is not a pure period such as 2 days and 3 hours.
We actually also accept 2015M1 for months; 2015Q1for quarters.
OK, I propose we go with the XSD style duration. @femtotrader would you like to submit a PR?
@djvanderlaan you are quite right re "points in time" vs duration. I like your method of being explicit though generally i would just interpret as a point in time e.g. 2015-Q1 or similar. Also, I'm interested to hear about your project - is it public?
Sorry @rgrp I'm quite busy these days (probably until december). So don't expect a PR from me. Sorry.
@femtotrader no problem - and thanks for all the contributions so far! We'll look to get that PR in.
OK, about to submit fix for this. Two things:
[jts][m]: add duration type to list of field types - fixes #210.
Add "duration" type
Referenced in #48