> A warn/carp perhaps. Even so, though. I don't see why my parser needs to > know anything about the formatter (it was given the input in good faith > and happily parsed it), or why I should wrap my formatter to > make sure things like '-0500' get 'normalized', while letting through > other things. What if '-0500' just happens to be the format I noticed > and there are others that can slip through and cause a warning?
Speaking as an end user! I think that a module should either a) do what the user expects or b) die because it's not possible to do exactly what the user asked for. As I said I don't think turning -0600 into UTC is reasonably what the user asked for. ftp://ftp.rfc-editor.org/in-notes/rfc2445.txt under 4.6.5 Time Zone Component Note: The specification of a global time zone registry is not addressed by this document and is left for future study. However, implementers may find the Olson time zone database [TZ] a useful reference. It is an informal, public-domain collection of time zone information, which is currently being maintained by volunteer Internet participants, and is used in several operating systems. This database contains current and historical time zone information for a wide variety of locations around the globe; it provides a time zone identifier for every unique time zone rule set in actual use since 1970, with historical data going back to the introduction of standard time. A possible option would be to add TZ's A-Z (like the military) to DateTime::TimeZone::. And define all of the properties that are asked for under the RFC. There is even "The optional "TZURL" property is url value that points to a published VTIMEZONE definition." I think these new TZ's could be very useful. > Or should I just wrap the formatter in a 'no warnings;' and have the > code not warn if warnings are off? I prefer the DBI style of setting attributes at creation. 'RaiseError => 1' > Could always have it as an option on new() I suppose, but (Builder > notwithstanding) I've not a fondness for adding lots of options. Sure ya don't. :) > warning and without my code having to do much. I do recognise your > position and can see merit in it, it's just not where I want to go. We're on the same side. I think DateTime::Format::ICal should support any DT object. On the other hand I may not be competent enough to get a vote. :) Cheers, -J --
