* Joshua Hoblitt ([EMAIL PROTECTED]) [26 Mar 2003 20:44]:
[...]
> 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.
Depends. Did they want output with offset, or did they want to represent
a particular time and date? If the former, they chose the wrong format.
If the latter, a conversion to UTC should be good.
[...]
> 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.
So, how do I represent Adelaide's date+time. Assume I've been given
+09:30 as my offset. How does this translate to military A-Z?
[I'd check the other url you sent me but forgot to look at it at home;
currently at work with no graphical browser]
> > 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'
That works for me.
> > 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. :)
=) Been having fun the past day or so, writing modules with as little
redundancy as possible. Thus there's a master class that has a
"declare_fields" method that is several layers of syntactic sugar on
Params::Validate, Class::Container and such. Just so that my actual
implementation is as small as possible.
> > 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. :)
Well, I was amused earlier to find that ICal and W3CDTF are opposites.
ICal doesn't support offset; W3CDTF only supports offsets. So wherever
this argument goes, one should be able to apply it to the W3CDTF module
too.
Although being limited to the other way is slightly different:
Given tz of Australia/Sydney, e.g. right now:
Fri Mar 28 17:10:56 2003
To convert to W3CDTF, do we make it into:
2003-03-28T06:10:56Z
or 2003-03-28T17:10:56+11:00
Then, next week, at the same time:
2003-04-04T07:10:56Z
or 2003-04-04T17:10:56+10:00
(We go off DST on Sunday morning apparently.)
Or should the module just croak?
Basically, the question is, I think:
+ If we can represent a date/time in a particular format,
but with having to lose some sort of information (e.g.
explicit timezone or offset or attoseconds), should we?
cheers,
--
Iain. <http://eh.org/~koschei/>
