[dragontamer]

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]

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]

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