what special font/characters is this article using?
in that scorecard table i got all same-looking boxes. yes/no Y/N T/F x/o would have been much more readable. And also in all bullet points also see boxes..
Python datetime pitfalls, and what libraries are (not) doing about it
71–80 of 150 posts
Re: Python datetime pitfalls, and what libraries are (not) doing about it
#72[deleted]
Re: Python datetime pitfalls, and what libraries are (not) doing about it
#73I will state this briefly as a tangent. This article mentions third party libraries; the top are Arrow and Pendulum. These are a wellspring of subtle bugs due to a decision they made that I suspect is based off the Javascript library Moment: They conflate Dates, Times, and Datetimes, as a single type. If you are using their Arrow etc type to represent a Date or Time, the resulting code will be fragile, and fail in surprising ways. Additionally, if my function signature accepts a time or date, you have no way of validating the parameter, and can do things like ask for "seconds" on a date. The moment/arrow/pendulum community advocates that the concept of a date or time individually is meaningless; I disagree. It is application specific, and there are applications that call for any of the 3 variants.
Python's builtin `datetime` library has flaws as pointed out in the article, but is safer than Arrow or Moment. I think Rust's Chrono lib is the best datetime library I've seen, in terms of not surprising you with errors.
Re: Python datetime pitfalls, and what libraries are (not) doing about it
#74Really, there is no good technical solution for this, because in part, it is not even a technical problem. The laws about timezones, etc, very from country to country, from year to year etc. And some parts of the world are claimed by two or more different countries, each one of which has an opinion about what time it should be there. One might say "well lets skip all this political b.s. and do everything in UTC" but…
I think they could improve the quality of life of the users a lot without addressing the "high frequency trading inside a jetplane flying against the rotation of the earth" edge case lol
(not to diminish having an accurate understanding of time ofc, GPS is the main example of an application, etc)
Re: Python datetime pitfalls, and what libraries are (not) doing about it
#75Best 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 wouldn't use an int. Some things use milliseconds since 1970 instead of seconds to get sub-second precision without involving double, and you need to read the docs to understand what is expected. Or you can just pass a DateTime object standard for the language if running in a single binary, or something like ISO 8601 when there's a network in between. Databases can often store DateTime objects sanely.
> Some things use milliseconds since 1970 instead of seconds to get sub-second precision without involving double
Or be like JS which uses both floats and milliseconds as its date format. That to me feels like taking worst parts of every option. But then, making fun of JS is like shooting fish in the barrel
Re: Python datetime pitfalls, and what libraries are (not) doing about it
#76Earlier quoted context omitted.
I wouldn't use an int. Some things use milliseconds since 1970 instead of seconds to get sub-second precision without involving double, and you need to read the docs to understand what is expected. Or you can just pass a DateTime object standard for the language if running in a single binary, or something like ISO 8601 when there's a network in between. Databases can often store DateTime objects sanely.
64 bit unsigned integer nanoseconds gets you out to 584 years (that's the year 2554 if you're using the Unix epoch). That's good enough for me to use universally for passing times around in the internals of my code. User input and output are going to and from that representation. Half as many, of course, if you use a signed integer. If you don't need nanoseconds, then use microseconds and you get 292 thousand years t…
tbh using signed 64 bit microseconds with ISO-8601 0000-01-01 as epoch has certain elegance to it and should cover fairly wide range of use-cases.
Re: Python datetime pitfalls, and what libraries are (not) doing about it
#77from 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, ) Why so many different types? Doesn't ZonedDateTime cover all of the other use cases?
No. First, there's a fundamental difference between naïve datetimes and timezone-aware datetimes. Try to combine them in one representation, and you are guaranteed to end up with a broken datetime library that spawns endless blog posts attacking it. Second, there's a more subtle distinction between a datetime which has a known timezone and one which merely has a known instantaneous offset. A timezone is essentially a…
IMO, any program using naive timestamps is probably doing something wrong. Same with fixed offsets (except UTC obviously).
For local time zone, how often does the local time zone change, and you want to modify all timestamps in the system? That actually seems like a huge pitfall
Re: Python datetime pitfalls, and what libraries are (not) doing about it
#78Earlier quoted context omitted.
This is the only sane policy. Timezone conversion must be delayed to the very last moment before displaying time to users. If I needed to define a daily alarm in a local wall clock time, I'd happily deal with a zoneless dateless hour-minute tuple and determine the alarm time by combining a date and a time using a timezone. Right after I'd convert that and handle the rest in UTC.
> This is the only sane policy. Timezone conversion must be delayed to the very last moment before displaying time to users. No, this only works for datetimes in the _past_. For future datetimes you often must store the datetime in the user's (IANA) timezone. Otherwise your application could be off. And your app could be off by more than one hour. In 2011 Samoa moved across the international date line. See https://ww…
Thank god someone in the thread understands the problem. Everyone saying "just make everything UTC and convert" is both throwing away information and making it impossible to do future calculations.
"Schedule a 1-1 with my boss every two weeks at 1 PM"
If you take my local time zone, convert it to UTC which puts my meeting at say 9AM UTC, schedule every two weeks at 9AM UTC and convert back to my local time zone it will be wrong when I hit change DST.
But if I instead store the (datetime, zone) pair when I say "1PM fourteen calendar days from now in zone" it will always be correct.
The UTC "trick" only works when your problem domain is representing specific moments in time.
Re: Python datetime pitfalls, and what libraries are (not) doing about it
#79Earlier quoted context omitted.
GMT does not have DST. It is only slightly different from UTC. That said, you should really use UTC. I think you are confusing it with British Summer Time which is GMT +1
>That said, you should really use UTC. No, that "store UTC everywhere" is often repeated but it's incorrect advice when applied to future human-constructed datetimes such as appointments or social events. Future "human-interpreted wall-clock" datetimes cannot be unambiguously stored as future UTC values with perfect roundtrip fidelity. I've tried to explain the difference in previous comment: https://news.ycombinator…
That is a good point, but fortunately a rare case.
The other problem is that when you are using human inputs such as appointments you may not know which is appropriate. If I arrange a meeting with someone in another timezone, and there is such a change, how can a system know whether I want the UTC time, my timezone, or the other person's timezone.
I am not sure there is a good way to do this in many cases. As you say some culturally defined times are definitely tied to the local timezone, but a lot of things will not be. There is a loss of information, but that information may not be useful on many cases.
I think I agree with you in that there is no universal solution. However, store UTC is probably good enough a lot of the time. In general, timezone changes would be announced well ahead of time so UTC would be fine except for times fixed far ahead.
I have actually lived through timezone changes that were decided on in emergency circumstances (Sri Lanka faced with a severe electricity shortage) and the result was chaos. People genuinely did not know whether an appointment would take place in "old time" or "new time"! No system devised earlier could have coped with that because intent was no unambiguous.
Re: Python datetime pitfalls, and what libraries are (not) doing about it
#80Earlier 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.
> don’t know what you mean by “4 pm local time”
It means “whenever it is 4pm wherever you are”.
As in, i want my alarm to go off at 4pm everyday regardless of whether i am traveling.
Python calls it a “naive” time, it has no timezone or offset. Its just a data structure that says “4pm” rather than “4pm eastern time”
An example ive used is when a user had to specify schedules for a digital menu board system. When the user says breakfast ends at 10am, that means wherever the digital menu board is located, not “10am where i was when i set the schedule”. It also doesn’t mean “end breakfast an hour early/late when daylight savings occurs”
It makes sense in any context where you need to do something at a certain time each day, and you specifically don’t mean “do this thing exactly every 24hrs”