Re: [Geotools-devel] jdbc negative dates

[Jody Garnett]

Thanks Justin, I am happy to fix up a few headers and merge - I like how
the date conversion was handled int the filter visitor.

If I include this in the beta2 can I ask a few of the people tagged in on
this thread to help out with the testing :)

--
Jody Garnett

On 15 April 2016 at 15:34, Justin Deoliveira  wrote:

> 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 
> wrote:
>
>> On Fri, Apr 15, 2016 at 2:05 AM Andrea Aime 
>> wrote:
>>
>>> On Fri, Apr 15, 2016 at 5:31 AM, Justin Deoliveira 
>>> 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 

Re: [Geotools-devel] jdbc negative dates

[Justin Deoliveira]

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

> On Fri, Apr 15, 2016 at 2:05 AM Andrea Aime 
> wrote:
>
>> On Fri, Apr 15, 2016 at 5:31 AM, Justin Deoliveira 
>> 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 

Re: [Geotools-devel] jdbc negative dates

[Justin Deoliveira]

On Fri, Apr 15, 2016 at 2:05 AM Andrea Aime 
wrote:

> On Fri, Apr 15, 2016 at 5:31 AM, Justin Deoliveira 
> 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!

Re: [Geotools-devel] ImageMosaic API refactor proposal

[Simone Giannecchini]

Ciao Niels,
we are looking into this and comparing with some work that have in the
pipeline which might extend the work you are doing with respect to
harvesting.

I like the general idea pretty much, I have a few quick questions/obs?

-1- Can you clarify this sentence?

"to replace the default direct granule access with a renderable graph
(for reprojection)"

-2- Stupid thing but in ImageMosaic I would go for add/removeRaster
rather than *Coverage

I will talk to Andrea and Daniele to add more.

That said, it might be worth to have a look at the code when it start to settle.



Regards,
Simone Giannecchini
==
GeoServer Professional Services from the experts!
Visit http://goo.gl/it488V for more information.
==
Ing. Simone Giannecchini
@simogeo
Founder/Director

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob:   +39  333 8128928

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.


On Wed, Apr 6, 2016 at 10:33 AM, Niels Charlier  wrote:
> Hello Devon,
>
> Directory walking is part of the harvesting process, which is at the moment
> implemented inside the ImageMosaicReader (see the inner class
> HarvestedResource).
> In the API, there is a separate MosaicHarvester interface, as well as a very
> light ImageMosaicReader with all the logic inside the ImageMosaic class.
> With this API, we can either do one of these two thing to customise
> harvesting:
> 1. Write our own reader and use all the mosaic functionality through the
> ImageMosaic class.
> 2. Write our own implementation of MosaicHarvester for a customised
> harvesting process and plug it into the ImageMosaicReader.
>
> Does that make any sense?
>
> Kind Regards
> Niels
>
>
> On 06-04-16 01:48, Devon Tucker wrote:
>
> For my own part, Niels maybe you could throw in some small examples of how
> these API changes would be used in practice to accomplish some of the items
> in the description? For example, how could I customize the directory walking
> with the new API?
>
> Thanks,
> Devon
>
> On Tue, Apr 5, 2016 at 4:44 PM, Devon Tucker  wrote:
>>
>> Hi all,
>>
>> Just noticed that there wasn't a dedicated email thread for this proposal
>> and figured I'd kick one off since I've also been involved in it.
>>
>>
>> https://github.com/geotools/geotools/wiki/Refactor-ImageMosaic-for-extensibility
>>
>> I think the description gives a pretty good rationale for what we want to
>> accomplish with this proposal and I'd like to solicit any discussion,
>> advice, feedback, etc. from everyone.
>>
>> Cheers,
>> Devon
>
>
>
>
> --
>
>
>
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
>
> --
>
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>

Re: [Geotools-devel] jdbc negative dates

[Andrea Aime]

On Fri, Apr 15, 2016 at 5:31 AM, Justin Deoliveira 
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.
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.

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?

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

Re: [Geotools-devel] jdbc negative dates

[Jody Garnett]

I saw the following:

 GregorianCalendar cal = new GregorianCalendar();
 cal.clear();
 cal.set(-500, 0, 1);

And was not sure what the set method was doing .. I thought it would be
adjusting when the calendar started counting from. Reading the docs shows
calendar is set for 500 BC, Jan 1st ... sigh. Digging into the
Calendar.Builder it does look like we can make our own calendars, but it
looks like madness[1].

Another time ...if there is interest we can talk to Ben's friends from the
GeoSciML crowd who would literally be all over this.

As for the original patch - it would be great if we could keep XDate from
leaking out into the client code but I will understand if it is not
possible.

Jody

[1]
http://classicprogrammerpaintings.tumblr.com/post/14264919/javautildate-salvador-dali-oil-on-canvas-1931







--
Jody Garnett

On 14 April 2016 at 20:54, Justin Deoliveira  wrote:

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