3 ms·

Postgres's time handling types are elaborate, and probably the best I've personally worked with. Timestamp with TimeZone (including DST + timezone offset) is a

Postgres's time handling types are elaborate, and probably the best I've personally worked with. Timestamp with TimeZone (including DST + timezone offset) is a different type from timestamp without TimeZone (ie: normalized to GMT). Timestamp - Timestamp results in "interval". Perhaps my method I was discussing doesn't work. But the overall idea that "Timestamp" needs to be a different type than "Interval", is pretty key IMO to handling date/times appropriately.

hfkwer 3y ago
Same in C#. DateTime, DateTimeOffset, TimeSpan.
- WalterBright 3y ago
  Everybody has this painful urge to reinvent the trivial in an incompatible way.
WalterBright 3y ago
> is pretty key IMO to A time_t can handle intervals just fine. time_t interval = t1 - t0;
- dragontamer 3y ago
  time_t will not handle daylight savings time conversions like Postgresql does. Unambiguously resolving "Timestamp at Eastern Time - Timestamp at Arizona Time" is not as simple as you might think. Postgresql handles this case. Trying to make "time_t" handle all cases is a mistake. We need like 3 to 4 types at a minimum to handle all of the edge cases that occur in the real world. (And if anyone teaches me of any more complications, maybe we'll need even more types)
  - WalterBright 3y ago
    The idea is to store all times as time_t in UCT, and do all time calculations in UTC. Do conversions to/from local time only as a first and last step. It's the only sane way to do it. The D runtime library does that, and it has proven to be robust and sane. We're also recommending that users do the same thing with different character representations - do all calculation and processing in UTF-8. Other sets are translated upon input into UTF-8, and the UTF-8 is translated to other character sets only on output.
    - dragontamer 3y ago
      > Do conversions to/from local time only as a first and last step. Cool. Now how do you enforce that? Spoiler: have the local-time be reported as a TimestampWithTimeZone. When you're doing calculations, make them all Timestamps. When you're done, you can remember that you've converted from internal UTC-timestamps into the proper output format because you'll have a TimestampWithTimezone again. ----------- We're programmers. We have problems that are simple and enforceable through compiler constructs called "The Type System". Why have the human figure out if they have time-zone back-and-forth correctly or otherwise made a mistake (ex: adding code to the wrong "part of the process" and accidentally mucking with a TimestampWithTimeZone input/output variable rather than the internal Timestamp-UTC-only type variables?) Just... leave the job of checking this entire process to the compiler. If your n00b coworker messes up, the type system catches it and we're all set.

hfkwer 3y ago

Same in C#. DateTime, DateTimeOffset, TimeSpan.

WalterBright 3y ago
Everybody has this painful urge to reinvent the trivial in an incompatible way.

WalterBright 3y ago

> is pretty key IMO to A time_t can handle intervals just fine. time_t interval = t1 - t0;

dragontamer 3y ago
time_t will not handle daylight savings time conversions like Postgresql does. Unambiguously resolving "Timestamp at Eastern Time - Timestamp at Arizona Time" is not as simple as you might think. Postgresql handles this case. Trying to make "time_t" handle all cases is a mistake. We need like 3 to 4 types at a minimum to handle all of the edge cases that occur in the real world. (And if anyone teaches me of any more complications, maybe we'll need even more types)
- WalterBright 3y ago
  The idea is to store all times as time_t in UCT, and do all time calculations in UTC. Do conversions to/from local time only as a first and last step. It's the only sane way to do it. The D runtime library does that, and it has proven to be robust and sane. We're also recommending that users do the same thing with different character representations - do all calculation and processing in UTF-8. Other sets are translated upon input into UTF-8, and the UTF-8 is translated to other character sets only on output.
  - dragontamer 3y ago
    > Do conversions to/from local time only as a first and last step. Cool. Now how do you enforce that? Spoiler: have the local-time be reported as a TimestampWithTimeZone. When you're doing calculations, make them all Timestamps. When you're done, you can remember that you've converted from internal UTC-timestamps into the proper output format because you'll have a TimestampWithTimezone again. ----------- We're programmers. We have problems that are simple and enforceable through compiler constructs called "The Type System". Why have the human figure out if they have time-zone back-and-forth correctly or otherwise made a mistake (ex: adding code to the wrong "part of the process" and accidentally mucking with a TimestampWithTimeZone input/output variable rather than the internal Timestamp-UTC-only type variables?) Just... leave the job of checking this entire process to the compiler. If your n00b coworker messes up, the type system catches it and we're all set.