> On 23/08/2022 14:38 CEST Peter J. Holzer <hjp-pgsql@xxxxxx> wrote:
>
>
> On 2022-08-23 10:25:12 +0100, Simon Riggs wrote:
> > On Mon, 22 Aug 2022 at 11:14, stefan eichert <stefaneichert@xxxxxxxxx> wrote:
> > > In order to deal with all dates, historical and prehistoric ones, in
> > > a consistent way, the implementation of timestamps/dates for before
> > > 4713 BC would be very helpful, as we really do have dates before
> > > 4713 BC we are working with, that in some cases also have
> > > information on months respectively days.
> >
> > One possibility is to store dates as the INTERVAL datatype, using the
> > convention for Before Present, rather than worrying about BC/AD.
> >
> > create table arch (i interval year);
> > insert into arch values ('-5000 years');
> > select * from arch;
> >
> > i
> > -------------
> > -5000 years
>
> [Disclaimer: I am not an archeologist]
Me neither ;)
> I think this works well if you know an approximate age. If something is
> about 5000 years old now, it will still be about 5000 years old next
> year and even in ten years.
>
> But it breaks down if you already have a relatively precise date.
>
> 4980 years before now probably should be 4981 years before now next year
> and definitely 4990 years before now in ten years. So you would have to
> continuosly update those values.
Would be easier to store the estimated age and the assessment date so the age
doesn't have to be updated until it's reassessed. The time from assessment to
now can be handled as you described: either the age is still considered roughly
the same or it increases as time between assessment and now increases.
--
Erik
