Rick Measham wrote:
2. Create DateTime::TimeZone::Olson::XS
- The Olson Database is already an open-source, free distributable C
library, would we not save considerable space/memory by creating an XS
interface to the library?
You would still have to create the timezone singletons -- unless you're
You would still have to create the timezone singletons -- unless you're
suggesting that these would be destroyed when not in use, you would
still end up running into the same memory issues once enough timezone
objects have been created.
And you wouldn't be able to take advantage of page
You would still have to create the timezone singletons -- unless you're
suggesting that these would be destroyed when not in use, you would
still end up running into the same memory issues once enough timezone
objects have been created.
And you wouldn't be able to take advantage of page
Is this ALL each timezone provides, and nothing else? Does anything directly
access timezone object structures in any other way? Because if not, it
should be pretty easy to create an XS wrapper to implement only these
functions, even say by accessing the POSIX zoneinfo database given a
Is this ALL each timezone provides, and nothing else? Does anything
directly
access timezone object structures in any other way? Because if not, it
should be pretty easy to create an XS wrapper to implement only these
functions, even say by accessing the POSIX zoneinfo database given a
My point really is that if each timezone object only has to obey the
method
interface (which is about 10 methods and only 2 of those really require
any
calculations) and nothing inspects the objects internally or requires
anything else from them, then it should be pretty easy to create
