glaredb icon indicating copy to clipboard operation
glaredb copied to clipboard

why is microseconds the default for `timestamp` fields?

Open universalmind303 opened this issue 1 year ago • 5 comments

Description

> create table timestamps (t timestamp);
Table created
> describe timestamps;
┌─────────────┬────────────────────┬─────────────┐
│ column_name │ data_type          │ is_nullable │
│ ──          │ ──                 │ ──          │
│ Utf8        │ Utf8               │ Boolean     │
╞═════════════╪════════════════════╪═════════════╡
│ t           │ Timestamp<µs, UTC> │ true        │
└─────────────┴────────────────────┴─────────────┘

I'd kind of expect it to be nanoseconds considering our usage of nanos elsewhere

universalmind303 avatar Feb 02 '24 20:02 universalmind303

Mainly because it's the default for Postgres.

Name Storage Size Description Low Value High Value Resolution
timestamp [ (p) ] [ without time zone ] 8 bytes both date and time (no time zone) 4713 BC 294276 AD 1 microsecond
timestamp [ (p) ] with time zone 8 bytes both date and time, with time zone 4713 BC 294276 AD 1 microsecond
date 4 bytes date (no time of day) 4713 BC 5874897 AD 1 day
time [ (p) ] [ without time zone ] 8 bytes time of day (no date) 00:00:00 24:00:00 1 microsecond
time [ (p) ] with time zone 12 bytes time of day (no date), with time zone 00:00:00+1559 24:00:00-1559 1 microsecond
interval [ fields ] [ (p) ] 16 bytes time interval -178000000 years 178000000 years 1 microsecond

vrongmeal avatar Feb 09 '24 15:02 vrongmeal

  • For those of you playing along at home, Janurary 1, 4713 BC is the epoch of the current Julian period used in Julian Day Number system.
  • @vrongmeal I suspect that the second row of this chart is incorrect, given that the timezone should take up some amount of space.

tychoish avatar Feb 12 '24 23:02 tychoish

@vrongmeal I suspect that the second row of this chart is incorrect, given that the timezone should take up some amount of space.

Postgres stores timezone info in the datatype and the value consists of a UTC timestamp. So this is OK.

vrongmeal avatar Feb 13 '24 09:02 vrongmeal

Postgres stores timezone info in the datatype and the value consists of a UTC timestamp. So this is OK.

Indeed!

Looks like Postgres stores everything with a timestamp, and the "without timetamp" variant of the type is just "timestamp ignored" and exists for formal compliance with the SQL standard... (so "no timestamp" is just "UTC").

tychoish avatar Feb 13 '24 10:02 tychoish

@universalmind303 is there something that we shold do here?

tychoish avatar Feb 19 '24 16:02 tychoish