BurntSushi
commented
1 month ago 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.
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_Yorktime 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.)