search

52North / IlwisCore

Integrated Land and Water Information System (ILWIS) is a remote sensing and GIS software. ILWIS Core is the functional center of ilwis4..
http://52north.org/communities/ilwis/
34 stars 13 forks source link

itTIME -> itDATETIME = itTIME | itDATE or TimeInterval._mode #39

Closed pokulo closed 10 years ago

pokulo commented 10 years ago

Some formats like shapefile (dbf) only support date (YYYMMDD) as a data type. Similarly sometimes people only want to handle dates or times, so the should globally be able to set an ilwisType.

More concrete: Here I need to decide, if the user wanted to handle dates, times or both together, otherwise the user always gets the error: DateTime not supported, even though the shapefile said OFTDate or OFTTime instead of OFTDateTime.

I considered using the TimeInterval class to store the Time::Mode{mDATE,mDATETIME,mTIME} but the I realized, that the implementation looses this information here.

So please consider introducing itDATE and itDATETIME or extend the TimeInterval class, so it can store and tell the Mode.

ridoo commented 10 years ago

In my opinion representing a time string is just a formatting issue. This however could be a default (perhaps iso8601) but should also be free for different formats. Storing time as milliseconds (or even with more precision) is just fine as long there is a method passing an implementation of a time formatting Interface. That kind of formattwr implementations could also hold implementation to read different kinds of time formats (YYYYMMDD, YYYY-MM-DD, YYYY/MM/DD, YYYY/DD/MM, and many more).

pokulo commented 10 years ago

you are right, most of what you mentioned (no milliseconds yet) is already implemented. The problem is more about a consistent handling of a precision attribute (called Time::Mode) through all the Time.... classes, so we know in the end, how to format/represent the Time (DateTime), if we translate it to external format, just like i try in GDALConnector.

MartinSchouwenburg commented 10 years ago

TimeInterval has now a mode attribute. It will inherit the mode from the Time objects that were used to create them. ;caught some (needed)mode changes in the time class. Time zone is not yet in the class, will probably in the near future

pokulo commented 10 years ago

when i try to clone the range (TimeInterval) here the information about _vt (itDATE) get lost again. Is there a better way of setting the range of a Datadefinition? Or how to make sure, _vt element gets always cloned as well.

MartinSchouwenburg commented 10 years ago

was simply missing from the clone function of timeinterval. I added it

pokulo commented 10 years ago

seems to work now