DateTime::TimeZone issues...

2003-11-12 Thread Rob Mueller
Hi I help develop an email website (http://www.fastmail.fm) and recently we wanted to move over to providing proper timezone support for users (eg give us a location, and we'll keep the time up to date, rather than having to change for daylight savings every 6 months). As part of this, we were goi

Re: DateTime::TimeZone issues...

2003-11-12 Thread Rob Mueller
<...> > > Having a look at the code, I noticed that each timezone has it's own class, > > and also a lot of data in perl structures. I'm not really sure why the > > timezone classes were developed this way, it seems fine for a simple case > > where you only need a couple of timezones, but in a case

Re: DateTime::TimeZone::Lite and DateTime::TimeZone::Olson::XS

2003-11-17 Thread Rob Mueller
> > 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

Re: DateTime::TimeZone::Lite and DateTime::TimeZone::Olson::XS

2003-11-17 Thread Rob Mueller
> > 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 giv

Re: DateTime::TimeZone::Lite and DateTime::TimeZone::Olson::XS

2003-11-17 Thread Rob Mueller
> > 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 cre

Re: DateTime::TimeZone size

2005-07-07 Thread Rob Mueller
This is why I think the biggest win for memory would be having XS based time zones. This would also help speed somewhat, but I think the memory savings could be very, very substantial. If you look at the compiled Olson DB bits used by libc, they're fairly small binary files (<1-2k usually).

Re: DateTime::TimeZone in XS is ready in CVS

2005-07-13 Thread Rob Mueller
You're not somehow accidentally pulling some other bunch of modules in are you? Have you tried dumping the loaded modules in each case with something like: print Dumper([ sort keys %INC ]); And comparing them? What you're seeing definitely sounds weird, it offhand it sounds like something els