Where do you see that? Are we looking at the same patch? The only thing I
really see in the patch is converting to/from milliseconds to date and then
some logic to append a “BC” to encoded date literals when the date falls in
the BC era.
On Thu, Apr 14, 2016 at 9:33 PM Jody Garnett <jody.garn...@gmail.com> wrote:
> I think the patch takes the approach of adjusting the calendar time is
> being measured against.
>
> Can we be tricky and produce a calendar for each section of geological
> time :)
> On Thu, Apr 14, 2016 at 8:31 PM 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 :)
>>
>> I did do some searching around for libraries or any code that is able to
>> represent the full of geologic time but didn’t come up with much. If people
>> do know of such a thing out there let us know…
>>
>>
>>
>> On Tue, Apr 12, 2016 at 1:54 PM Jonathan Marino <mar...@mapstory.org>
>> wrote:
>>
>>> Thanks Justin. Much appreciated. Keep us posted if you can. This is an
>>> exciting, and critical piece of making MapStory work the way we've imagined.
>>>
>>>
>>>
>>> On Tue, Apr 12, 2016 at 3:47 PM, Justin Deoliveira <jdeol...@gmail.com>
>>> wrote:
>>>
>>>> Great, thanks for the input Jonathon and David. I think I have enough
>>>> to put together a proposal on how to improve the current patch. Going to
>>>> start that in a new thread.
>>>>
>>>> On Tue, Apr 12, 2016 at 1:38 PM Jonathan Marino <mar...@mapstory.org>
>>>> wrote:
>>>>
>>>>> Just to be clear from the MapStory end, to be honest, we don't really
>>>>> care the time resolution on negative time - milli, seconds, hours. Just
>>>>> whatever is the most viable pathway to go back to geologic (circa 4.5
>>>>> billion). We leave it to you to determine what you prefer.
>>>>>
>>>>> On Tue, Apr 12, 2016 at 2:57 PM, Justin Deoliveira <jdeol...@gmail.com
>>>>> > wrote:
>>>>>
>>>>>> Perfect, that is what I needed :)
>>>>>>
>>>>>> Ok, so having two types makes sense. One to be able to go back to
>>>>>> time zero but also limited in terms of resolution to seconds, and one
>>>>>> that
>>>>>> doesn’t go all the way back but gives you down the millisecond.
>>>>>>
>>>>>> Or do you think that two types is overkill and we can get away with
>>>>>> one type interpreted as seconds?
>>>>>>
>>>>>> On Tue, Apr 12, 2016 at 12:51 PM David William Bitner <
>>>>>> bit...@dbspatial.com> wrote:
>>>>>>
>>>>>>> The Earth is 4.5 Billion Years old. Milliseconds takes us to ~290
>>>>>>> Million Years Ago, Seconds can get us to ~290 Billion Years Ago. Using
>>>>>>> seconds allows us to encompass the full geologic record but allows for
>>>>>>> less
>>>>>>> precision than storing milliseconds.
>>>>>>>
>>>>>>> On Tue, Apr 12, 2016 at 1:47 PM, Justin Deoliveira <
>>>>>>> jdeol...@gmail.com> wrote:
>>>>>>>
>>>>>>>> Thanks David. I was clear that native postgresql timestamp couldn’t
>>>>>>>> do the job, but my question was whether bigint had a big enough value
>>>>>>>> space
>>>>>>>> for geologic time? If we interpret the value as milliseconds is it big
>>>>>>>> enough? Or do we need to interpret as seconds in order to go back far
>>>>>>>> enough?
>>>>>>>>
>>>>>>>> On Tue, Apr 12, 2016 at 12:00 PM David William Bitner <
>>>>>>>> bit...@dbspatial.com> wrote:
>>>>>>>>
>>>>>>>>> It's about the value space.
>>>>>>>>>
>>>>>>>>> Native PostgreSQL Timestamp can cover between 4713 BC to 294276
>>>>>>>>> AD.
>>>>>>>>>
>>>>>>>>> BigInt can cover between ~ -9 and +9 Quintillion
>>>>>>>>>
>>>>>>>>> Which converting to seconds (9 Quintillion / (365*24*60*60)) is ~
>>>>>>>>> 290 Billion
>>>>>>>>>
>>>>>>>>> And to milliseconds (9 Quintillion / (365*24* 60*60*1000)) is ~
>>>>>>>>> 290 Million
>>>>>>>>>
>>>>>>>>> On Tue, Apr 12, 2016 at 11:48 AM, Justin Deoliveira <
>>>>>>>>> jdeol...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Thanks for the info guys, You’ll have to bear with me as you walk
>>>>>>>>>> me through the nuances of representing time in this way.
>>>>>>>>>>
>>>>>>>>>> So in order to represent full geologic time do you need more than
>>>>>>>>>> just a numeric value? Or is that you just need a numeric type with a
>>>>>>>>>> bigger
>>>>>>>>>> value space?
>>>>>>>>>>
>>>>>>>>>> On Tue, Apr 12, 2016 at 10:31 AM David William Bitner <
>>>>>>>>>> bit...@dbspatial.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> With the added rub that millis does not allow to go back quite
>>>>>>>>>>> far enough to deal with geologic time. If the same mechanism was
>>>>>>>>>>> used
>>>>>>>>>>> (Postgresql Domain), It could be possible to create something like
>>>>>>>>>>> "bigdate_milli" and "bigdate_sec" or "bigdate" and "reallybigdate".
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Apr 12, 2016 at 11:28 AM, Justin Deoliveira <
>>>>>>>>>>> jdeol...@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Thanks David, that helps a lot.
>>>>>>>>>>>>
>>>>>>>>>>>> So to summarize the ask is to be able to store dates as
>>>>>>>>>>>> milliseconds from the epoch, and have the geotools datastore map
>>>>>>>>>>>> that to a
>>>>>>>>>>>> java date type . With the current patch that logic is triggered is
>>>>>>>>>>>> by using
>>>>>>>>>>>> a domain type of “bigdate” in postgres. And because of the way
>>>>>>>>>>>> type mapping
>>>>>>>>>>>> works in the data store we need some subclass (called XDate in the
>>>>>>>>>>>> patch)
>>>>>>>>>>>> in order to map back to the database.
>>>>>>>>>>>>
>>>>>>>>>>>> Do I have it right?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Apr 12, 2016 at 8:18 AM David William Bitner <
>>>>>>>>>>>> bit...@dbspatial.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> The rationale behind this is to be able to store dates beyond
>>>>>>>>>>>>> the PostgreSQL timestamp limit of 4713 BC to 294276 AD.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ian's patch allows for storage of the datetime as milliseconds
>>>>>>>>>>>>> from the Unix Epoch which gives roughly +/- 290 Million Years by
>>>>>>>>>>>>> storing as
>>>>>>>>>>>>> a bigint using a PostgreSQL Domain bigdate as a marker. ("CREATE
>>>>>>>>>>>>> DOMAIN
>>>>>>>>>>>>> bigdate bigint;" is all that means).
>>>>>>>>>>>>>
>>>>>>>>>>>>> The issue that MapStory/Geonode is running into currently is
>>>>>>>>>>>>> the requirement to be able to show the entire geologic record
>>>>>>>>>>>>> (the Earth is
>>>>>>>>>>>>> ~ 4.2 Billion years old), so even this patch doesn't make it all
>>>>>>>>>>>>> the way
>>>>>>>>>>>>> there (although storing the datetime as seconds from the Unix
>>>>>>>>>>>>> Epoch would
>>>>>>>>>>>>> cover roughly +/-290 Billion which WOULD do the job).
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, Apr 12, 2016 at 7:30 AM, Justin Deoliveira <
>>>>>>>>>>>>> jdeol...@gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> This was my finding as well… couldn’t make up what was going
>>>>>>>>>>>>>> on here… which makes me think there is perhaps more to this
>>>>>>>>>>>>>> patch on the
>>>>>>>>>>>>>> GeoNode side?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Rather than flying blind has anyone tried to reach out to Ian
>>>>>>>>>>>>>> Schneider, who afaik is the original author of the patch? If not
>>>>>>>>>>>>>> I can give
>>>>>>>>>>>>>> that a shot and hopefully get him to weigh in.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Tue, Apr 12, 2016 at 1:30 AM Andrea Aime <
>>>>>>>>>>>>>> andrea.a...@geo-solutions.it> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Tue, Apr 12, 2016 at 8:59 AM, Jody Garnett <
>>>>>>>>>>>>>>> jody.garn...@gmail.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Near as I can tell the point of this exercise is to provide
>>>>>>>>>>>>>>>> a mapping for bigdate:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> mappings.put("bigdate", XDate.class);
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Err yeah but I'm still lost, I can't see any such type in
>>>>>>>>>>>>>>> postgresql, nor
>>>>>>>>>>>>>>> I can find one searching the internet:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://www.postgresql.org/docs/9.3/static/datatype-datetime.html
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> And yet it's used in the test table creations... but if I
>>>>>>>>>>>>>>> run it locally:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> > gttest=# CREATE TABLE "bigdates" (id integer PRIMARY KEY,d
>>>>>>>>>>>>>>> bigdate);
>>>>>>>>>>>>>>> ERROR: type "bigdate" does not exist
>>>>>>>>>>>>>>> LINE 1: CREATE TABLE "bigdates" (id integer PRIMARY KEY,d
>>>>>>>>>>>>>>> bigdate);
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So... I assume bigdate is some extended type in postgresql,
>>>>>>>>>>>>>>> installed as an
>>>>>>>>>>>>>>> extension? Yet I cannot find one providing this data type.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'm all for helping, would just like to know what it's for
>>>>>>>>>>>>>>> instead of getting in
>>>>>>>>>>>>>>> a strange patch at face value.... there might be a cleaner
>>>>>>>>>>>>>>> way to solve this,
>>>>>>>>>>>>>>> mocking with converters and centralized converters can cause
>>>>>>>>>>>>>>> side effects.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> ************************************
>>>>>>>>>>>>> David William Bitner
>>>>>>>>>>>>> dbSpatial LLC
>>>>>>>>>>>>> 612-424-9932
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> ************************************
>>>>>>>>>>> David William Bitner
>>>>>>>>>>> dbSpatial LLC
>>>>>>>>>>> 612-424-9932
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> ************************************
>>>>>>>>> David William Bitner
>>>>>>>>> dbSpatial LLC
>>>>>>>>> 612-424-9932
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> ************************************
>>>>>>> David William Bitner
>>>>>>> dbSpatial LLC
>>>>>>> 612-424-9932
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 815.222.9088
>>>>> @MapStory <http://twitter.com/mapstory>
>>>>>
>>>>>
>>>
>>>
>>> --
>>> 815.222.9088
>>> @MapStory <http://twitter.com/mapstory>
>>>
>>> --
> --
> Jody Garnett
>
------------------------------------------------------------------------------
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
