Do you have any particular reason for preferring code generation over this technique? The branch I provide should act pretty much identically to the generated code:
1. builds the same tzinfo instances at runtime, and makes sure you get the same instance each time you request a named time zone.
2. is self contained, not relying on the system time zone database.
3. works as a Python egg, using pkg_resources to look up the compiled time zone files.
Furthermore, it has the following benefits:
1. it can be updated by slotting in new compiled time zone files, rather than needing to regenerate Python source files.
2. would make it possible to support a "localtime" timezone ($TZ environment variable, falling back to /etc/localtime), which could be useful for applications that want to display times in the user's local time zone without requiring additional configuration.
Do you have any particular reason for preferring code generation over this technique? The branch I provide should act pretty much identically to the generated code:
1. builds the same tzinfo instances at runtime, and makes sure you get the same instance each time you request a named time zone.
2. is self contained, not relying on the system time zone database.
3. works as a Python egg, using pkg_resources to look up the compiled time zone files.
Furthermore, it has the following benefits:
1. it can be updated by slotting in new compiled time zone files, rather than needing to regenerate Python source files.
2. would make it possible to support a "localtime" timezone ($TZ environment variable, falling back to /etc/localtime), which could be useful for applications that want to display times in the user's local time zone without requiring additional configuration.