tzdata
tzdata copied to clipboard
python
Should we ship the right/ zones?
I believe what we're shipping right now are the posix/ zones, which are what everyone uses. There's also the right/ database, which has leap second information and uses TAI instead of UTC or something (I'd have to dig into it more deeply to understand it better).
I think no one or very few people will notice if these are missing, and AFAIK, the leap second information is also available in an uncompiled form in tzdata.zoneinfo.leapyears, and neither zoneinfo.ZoneInfo nor dateutil.tz do anything with that information in the TZif file.
I think this is one of the last questions I'd like to answer before we go from release candidate to final release.
@FFY00 any thoughts?
Oh, one thing I'll note: It is a lot easier to start shipping the right/ zones later if someone needs them than it is to stop shipping them if we decide it was a mistake to do so. If we don't ship them, we can know with pretty high confidence that no one is relying on that fact (at least not for anything important) — anyone who needs them will file a bug complaining that they don't exist. If we do ship them, we can't know if we're breaking something important by removing them, since we can't see everything that depends on our modules.
These files are distributed out of necessity, the normal files will symlink to them. If we are in control of the symlinks, which I think we are but have not checked, I think we should just ship the final files, no posix/ or right/.
Since neither posix/ or right/ should be used directly, it shouldn't be a problem.
If someone really wants them in the future, we can re-evaluate.
Does this make sense?
These files are distributed out of necessity, the normal files will symlink to them. If we are in control of the symlinks, which I think we are but have not checked, I think we should just ship the final files, no
posix/orright/.Since neither
posix/orright/should be used directly, it shouldn't be a problem.
I think the question of "do we control the symlinks" is a bit under-defined. If zoneinfo and maybe dateutil were the only consumers of tzdata (which, at the moment, they almost certainly are), then it makes sense to say that we do not need the right/ zones, but presumably there could arise future libraries that use the right/ zones to give some improved leap second support or something, and those applications would handle presumably handle it by accepting an IANA key and then prepending right/ to get the "right" version.
Interestingly, if we ship both posix/ and right/, it brings up the question of whether we can even use symlinks; I think that is tricky because of uneven Windows support for the concept of a symlink. I'd have to look into what happens on Windows if we build a wheel with actual symlinks in it (though theoretically we could distribute platform-specific wheels).
I'm inclined to say this is a YAGNI situation and we can ship without right/ for now, but part of the goal of tzdata is to make it so pytz and dateutil and pendulum and any other random library doesn't need to vendor their own copy of the time zone database. In the long run, if we're going to try to be a one-stop-shop for time zone data, we may need to ship the full database, including right/.
I suggest to start with focusing on Python 3.9 zoneinfo module, and later reconsider the issue once other libraries comes in and ask for right/ directory.
Okay, so shipping right/ does make a bit of sense. Is there any con against shipping it? I can't think of anything.
Okay, so shipping right/ does make a bit of sense. Is there any con against shipping it? I can't think of anything.
It makes the ZIP file 1.6 MB larger and it's useless with Python 3.9 zoneinfo module, no?