auta...@urth.org wrote: >I'd like to hear from David Pinkowitz and Olivier Mengue on this.
Sure. >I'd be fine with new names for utility subs like this. Obviously there'd have >to be a deprecation period. I'm not intending to ever remove the old interfaces. They're cheap to retain indefinitely. >able DT::TZ without a conflict on an existing DateTime.pm. That's the idea. > When you release the new DT::TZ I'll release a new DateTime.pm >with fixed tests. Ah, I didn't grasp earlier that it was *DateTime*'s test suite that broke. That's a non-trivial issue. You should release the new DateTime straight away, or at least before the new DT:TZ goes out, so that current DT will always install OK with current DT:TZ. There has to be at least one DT version that can install with either flavour of DT:TZ. I think you've said that the current DT is actually OK with new DT:TZ in normal operation; if it were not then we might have to rethink. Changing DT to require new DT:TZ is a later stage which I don't really want to think about atm. >I think the message from TzFile is actually less informative. Heh, apparently we have different priorities. I find the old DT:TZ's message less informative because it doesn't say *why* the local time is invalid (it can also be because the zone was disused) and it doesn't say where in the code the error occurred. >the ideal would be to include the zone and the invalid local time in the >message. Yes, sounds good. If we're OK with changing the messages at all, I'm OK with putting this information into the messages from DT:TZ:Tzfile and DT:TZ:SystemV. (They'll both have to change, because DT:TZ:SystemV is used to implement the far future of tzfile zones.) >First, the module needs to just exist in the new distro. I think people might >be relying on it for docs. If the new distro doesn't replace it then they'll >be left with out of date docs, which is no good. Good point. Should probably have a .pm that doesn't load, containing POD pointing at the current location for the data. >As to how and when these docs get generated, I don't really care, I just want >the docs to be available after the distro is installed. It's tricky if you want that to be a literal installed POD file and want it up-to-date. Would you be happy with the access mechanism being something other than "perldoc $module_name"? It's easy to generate the current style of POD on the fly, just difficult to install it. >Yeah, I think shipping it would be a good idea. You can make a note of it in >the Changes file. OK. >Whatever works for you. As long as it's publicly available and in the distro >metadata, I'm happy. I just don't want the project to become less visible >after you take it over. I'll look into that. >Yeah, that's a good point. I guess I'm fine with not having comaint. OK, cool. -zefram
