My interpretation has always been:

> * Instant - an instantaneous point on the time-line
> * DateTime - full date and time with time-zone

These two do not have distinct types and are both handled via timestamp
with a timezone.

> * LocalDateTime - date-time without a time-zone

Arrow Timestamp without timezone (although as noted above the
representation we've used makes this the cause for debate).

I guess the alternative would be to have a first class LocalDateTime type.



On Tue, Jun 15, 2021 at 9:14 AM Antoine Pitrou <anto...@python.org> wrote:

>
> Le 15/06/2021 à 16:53, Adam Hooper a écrit :
> >     - *"Datetime"* lets you extract fields, parse strings, format to
> string.
> >     You can't sort (because clocks sometimes go backwards). You can't
> convert
> >     between timestamps and future datetimes (because timezones change).
>
> Not true if the timezone is UTC, though.
> (which is a strong argument, IMHO, for representing all values in the
> UTC reference, regardless of any optional "timezone" information)
>
> Regards
>
> Antoine.
>

Reply via email to