41–50 of 150 posts
Across all languages, what are the best libraries, with least amount if pitfalls? (java.time seems good, anything even better elsewhere?)
I don't think any of the DST complaints are legitimate. If doing work involved with timestamps, not keeping everything in GMT is questionable. GMT is the UTF-8 of timestamps: the low common-denominator rules. The datetime library is mechanism. DST is policy. Policy is wildly variable and your system library would be unmaintainable if it had to chase policy. Just say no.
I tend to prefer: - Things happen/happened at UTC times - Things will happen at zoneless time + IANA DB label. Though there are some edges. Obviously it's possible to pre-apply and convert to UTC, which is okay, but whether that makes sense to do in practice varies some. Future UTC time of often worthless for understanding human centric dates and times.
from whenever import (
# For the "UTC everywhere" case
UTCDateTime,
# Simple localization sans DST
OffsetDateTime,
# Full-featured IANA timezones
ZonedDateTime,
# The local system timezone
LocalDateTime,
# Detached from any timezones
NaiveDateTime,
)
> # The local system timezone > LocalDateTime, Here’s my feedback: one should essentially never use “local” time. I would even argue that the existence of systemwide local time is a historical mistake. Why would you ever want to use the “local” timezone of the system on which you are running? If the user is literally sitting in front of a monitor plugged in to the machine, it might be appropriate (but it should be a…
Best code strategy here is twofold. 1. Maximize the code context where date/time is represented as a simple count of Unix epoch seconds. 2. Never pass calendar/clock representations through API methods. 3. Always pass a timezone to methods that require it. 4. Counting, like time, is hard. The only contexts I see where calendar/clock representation are needed are: - Accept calendar/clock info from the user or external…
> # The local system timezone > LocalDateTime, Here’s my feedback: one should essentially never use “local” time. I would even argue that the existence of systemwide local time is a historical mistake. Why would you ever want to use the “local” timezone of the system on which you are running? If the user is literally sitting in front of a monitor plugged in to the machine, it might be appropriate (but it should be a…
Then how do you express that something must happen at a date in the future at 4pm local time? If you use UTC based on today's expectation of daylight savings, they may have changed by the time this date happens.
For example, I read your comment three times, and I don’t know what you mean by “4 pm local time”. I don’t even have what I would consider to be a credible guess.
Across all languages, what are the best libraries, with least amount if pitfalls? (java.time seems good, anything even better elsewhere?)
I really like Go's "time" package. The only pitfall I can think of is that it doesn't really handle overflow at all. https://pkg.go.dev/time
Best code strategy here is twofold. 1. Maximize the code context where date/time is represented as a simple count of Unix epoch seconds. 2. Never pass calendar/clock representations through API methods. 3. Always pass a timezone to methods that require it. 4. Counting, like time, is hard. The only contexts I see where calendar/clock representation are needed are: - Accept calendar/clock info from the user or external…
I think you're on the right track but a timestamp should only count the actual number of seconds that have passed, not some half-measure that tries to align with the rotation of the earth.
The author provides this example to illustrate inconsistent handling of non-existent datetimes: # This time doesn't exist on this date d = datetime(2023, 3, 26, 2, 30, tzinfo=paris) # No timestamp exists, so it just makes one up t = d.timestamp() datetime.fromtimestamp(t) == d # False Criticisms: 1) The example would fail just as well for any datetime with given tzinfo. Because fromtimestamp returns native datetimes.…
If we are willing to adjust a tiny bit, there are options:
Option1: “01:59 is followed by 03:00”.
Option2: “clock changes forwards at 2am GMT+2” (GMT+2 is offset before the hour jump)
Earlier quoted context omitted.
Then how do you express that something must happen at a date in the future at 4pm local time? If you use UTC based on today's expectation of daylight savings, they may have changed by the time this date happens.
You start by figuring out what you’re even trying to do. For example, I read your comment three times, and I don’t know what you mean by “4 pm local time” . I don’t even have what I would consider to be a credible guess.