You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Like #18, I believe that POSIX TZ lookups are quite slow at present. I think we could save quite a bit of time by assuming that
the year for most requests will match the current year, and then pre-computing whatever information we need from that.
You might ask, why care about POSIX TZ strings? Who the heck uses those any more? Well, it turns out, just about everyone! In particular, POSIX TZ strings are actually embedded into TZif files from the zoneinfo database. They are used for determining time zone transitions that occur after the transitions in the TZif data. For example, if your zoneinfo database was compiled in "slim" mode, then the America/New_York time zone will only have explicit transitions up to 2007. After that, a POSIX TZ string is used. (When compiled in "fat" mode, many more transitions are pre-computed.)
The text was updated successfully, but these errors were encountered:
Another strategy is to cache the year from the previous lookup. Instead of biasing toward "now," we would bias toward locality. That is, that for most datetimes handled, probably a lot of them are close together in time.
This would probably be trickier to implement. The nice thing about caching for the current year is that one can do it at construction time and never need any synchronization. But caching the most recent year means you need to deal with synchronization which significantly complicates that approach.
So I still think it's probably worth starting with the current year. But maybe there is a better strategy.
BurntSushi
changed the title
adding caching mechanism for POSIX TZ lookups
add caching mechanism for POSIX TZ lookups
Aug 3, 2024
Like #18, I believe that POSIX TZ lookups are quite slow at present. I think we could save quite a bit of time by assuming that
the year for most requests will match the current year, and then pre-computing whatever information we need from that.
You might ask, why care about POSIX TZ strings? Who the heck uses those any more? Well, it turns out, just about everyone! In particular, POSIX TZ strings are actually embedded into TZif files from the zoneinfo database. They are used for determining time zone transitions that occur after the transitions in the TZif data. For example, if your zoneinfo database was compiled in "slim" mode, then the
America/New_York
time zone will only have explicit transitions up to 2007. After that, a POSIX TZ string is used. (When compiled in "fat" mode, many more transitions are pre-computed.)The text was updated successfully, but these errors were encountered: