Ok, here is my cut at this one:
https://github.com/geotools/geotools/pull/1173
It leans on the recent conversion from Date to Long added to
TemporalConverterFactory, and also adds the reverse conversion from Long to
Date.
The test case exercises reading the date values, as well as writing them
back, along with filtering.
On Fri, Apr 15, 2016 at 3:37 PM Justin Deoliveira <jdeol...@gmail.com>
wrote:
> On Fri, Apr 15, 2016 at 2:05 AM Andrea Aime <andrea.a...@geo-solutions.it>
> wrote:
>
>> On Fri, Apr 15, 2016 at 5:31 AM, Justin Deoliveira <jdeol...@gmail.com>
>> wrote:
>>
>>> Hey guys. So as I started on this I quickly came to the realization
>>> (which I apologize for not seeing the obvious before) but interpreting
>>> values as seconds won’t really buy us anything if we’re bound by the value
>>> space of long that’s used for java.util.Date.
>>>
>>>
>> Re-implementing a new date type based on seconds rather than milliseconds
>>> is far from a trivial effort as I am sure folks are aware so I think the
>>> best I’ll be able to do is clean up the original patch, which will still be
>>> limited to the +- 290 million year range. Apologies for the false hope :)
>>>
>>
>> Yep indeed. Also consider that we recently got in a converter going from
>> long -> Date, that might help simplify the original patch.
>>
>
> Potentially, although the conversion is this case is pretty simple… it’s
> just taking the long value as is and putting that into the date
> constructor. But if it’s already there in the converter might as well use
> it.
>
>
>> At risk of being obvious, do you really need a timeline that goes back
>> eons, and still allows seconds accuracy? Or even a day accuracy?
>> Normally when going that far back even a year is (insanely) high
>> granularity, and well, integer numbers we already handle at ease :-p
>>
>
>
>
>>
>> But yeah, if the requisite is to allow a single unified time
>> representation good for ages ago and at the same time your
>> yesterday detailed movements list, I guess a new type of Date is indeed
>> needed. I was wondering if maybe Joda-time
>> already faced a similar challenge, but I could not find an answer doing a
>> quick internet search.
>>
> I came up short looking for a solution to this one as well.
>
>>
>> One sneaky suggestion... is it that bad to just put a biginteger of sorts
>> in the database, keep it that way up to the
>> UI, and have the UI translate it in an appropriate way to a date?
>>
>
> Good question… I think having a type that can store as a long and go
> to/from date is general enough… but once you start putting constraints on
> the value like it represents seconds or years it’s starting to get pretty
> custom, and I agree, better to just have GeoTools model it as a number
> directly and have the application deal with the interpretation of that.
>
>>
>> Cheers
>> Andrea
>>
>> --
>> ==
>> GeoServer Professional Services from the experts! Visit
>> http://goo.gl/it488V for more information.
>> ==
>>
>> Ing. Andrea Aime
>> @geowolf
>> Technical Lead
>>
>> GeoSolutions S.A.S.
>> Via di Montramito 3/A
>> 55054 Massarosa (LU)
>> phone: +39 0584 962313
>> fax: +39 0584 1660272
>> mob: +39 339 8844549
>>
>> http://www.geo-solutions.it
>> http://twitter.com/geosolutions_it
>>
>> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>>
>> Le informazioni contenute in questo messaggio di posta elettronica e/o
>> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
>> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
>> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
>> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
>> darcene notizia via e-mail e di procedere alla distruzione del messaggio
>> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
>> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
>> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
>> principi dettati dal D.Lgs. 196/2003.
>>
>>
>>
>> The information in this message and/or attachments, is intended solely
>> for the attention and use of the named addressee(s) and may be confidential
>> or proprietary in nature or covered by the provisions of privacy act
>> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
>> Code).Any use not in accord with its purpose, any disclosure, reproduction,
>> copying, distribution, or either dissemination, either whole or partial, is
>> strictly forbidden except previous formal approval of the named
>> addressee(s). If you are not the intended recipient, please contact
>> immediately the sender by telephone, fax or e-mail and delete the
>> information in this message that has been received in error. The sender
>> does not give any warranty or accept liability as the content, accuracy or
>> completeness of sent messages and accepts no responsibility for changes
>> made after they were sent or for other risks which arise as a result of
>> e-mail transmission, viruses, etc.
>>
>> -------------------------------------------------------
>>
>
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
