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
>
------------------------------------------------------------------------------
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
