Re: Request for DateTime API addition: today() constructor

[Joshua Hoblitt]

> yeah, but then we're bordering on a truly ridiculous number of
> constructors, most of which are just syntactic sugar.  I'm afraid I'm
> going to go with Joshua's suggestion on this one.  It "feels" right
> because the other constructors already take a time_zone parameter, so this
> one should too.

So how do you want to do this?  Should ->from_epoch be changed to accept a timezone 
that it passes on to ->new or should ->now call -new on it's own?

-J

--

datetime.perl.org

[Joshua Hoblitt]

It would be nice to have a link the sourceforge cvs or the cvs viewer from 
datetime.perl.org/developer/.

http://sourceforge.net/cvs/?group_id=17187

and/or

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/perl-date-time/

Cheers,

-J

--

Re: ANNOUNCE: DateTime::Calendar::Julian 0.04 and ::Christian 0.01

[Dave Rolsky]

On Thu, 27 Mar 2003, Eugene van der Pijll wrote:

> What standard? I didn't override iso8601(), only datetime(). Those are
> not synonymous any longer in ::Julian.

I see.  I'm not sure if that's a good thing or not ;)

> If datetime() is there, as you say, as a convenient way to print both
> date & time, I think it would make sense to include a similar method in
> every calendar module, and to include in the output which calendar is used.

I gues ...

> (By the way, what should ::Julian->iso8601 return? If I follow the
> standard strictly, it should be the Gregorian date...)

Uh, umm, uh, umm, I dunno.  It probably should be an error or something
(or just not exist).  The ISO 8601 standard is really just about the
Gregorian calendar.


-dave

/*===
House Absolute Consulting
www.houseabsolute.com
===*/

Re: Request for DateTime API addition: today() constructor

[Dave Rolsky]

On Wed, 26 Mar 2003, Tim Bunce wrote:

> > >   now_local()
> > >   now_utc()
> > >   today_local()
> > >   today_utc
> >
> > Why not have the constructors take any timezone as an argument?
> >
> > ->now( 'utc' )
> >
> > or
> >
> > ->now( timezone => 'local' )
> >
> > or even
> >
> > ->now( timezone => 'floating' )
> >
> > If no arguments are specified you get still get UTC.
>
> You could, but I like the simplicity and clarity for these common cases.

yeah, but then we're bordering on a truly ridiculous number of
constructors, most of which are just syntactic sugar.  I'm afraid I'm
going to go with Joshua's suggestion on this one.  It "feels" right
because the other constructors already take a time_zone parameter, so this
one should too.


-dave

/*===
House Absolute Consulting
www.houseabsolute.com
===*/

Re: ANNOUNCE: DateTime::Calendar::Julian 0.04 and ::Christian 0.01

[Eugene van der Pijll]

Dave Rolsky schreef:
> On Wed, 26 Mar 2003, Eugene van der Pijll wrote:
> > - changed output of datetime() to 2000-01-01J00:00:00, to be
> >   different from Gregorian dates.
> >
> > (Dave, what is the datetime() method for?  It would be nice if every
> > Calendar module had at least one output method in common, returning a
> > compact, calendar-specific representation of the datetime.)
> 
> The datetime method is there just to provide a convenient, reasonably
> standard way to put both the date and time.  In the case of DateTime.pm,
> the output is actually a valid ISO 8601 datetime.  I don't know if
> overriding it like you did really makes sense, since what you're
> outputting definitely doesn't fit the standard.

What standard? I didn't override iso8601(), only datetime(). Those are not synonymous 
any longer in ::Julian.

If datetime() is there, as you say, as a convenient way to print both
date & time, I think it would make sense to include a similar method in
every calendar module, and to include in the output which calendar is used.

(By the way, what should ::Julian->iso8601 return? If I follow the
standard strictly, it should be the Gregorian date...)

Eugene


P.S. This change in datetime() causes one test in ::Christian to fail.
I've already uploaded v0.02. Oh, the embarrassment...

Re: ANNOUNCE: DateTime::Calendar::Julian 0.04 and ::Christian 0.01

[Dave Rolsky]

On Wed, 26 Mar 2003, Eugene van der Pijll wrote:

> from the ::Julian changelog:
>
> 0.04  2003-03-13
> - changed output of datetime() to 2000-01-01J00:00:00, to be
>   different from Gregorian dates.
>
> - removed bug in day_of_year calculation
>
> - removed "use Params::Validate", which was superfluous after v0.03
>
>
> (Dave, what is the datetime() method for?  It would be nice if every
> Calendar module had at least one output method in common, returning a
> compact, calendar-specific representation of the datetime.)

The datetime method is there just to provide a convenient, reasonably
standard way to put both the date and time.  In the case of DateTime.pm,
the output is actually a valid ISO 8601 datetime.  I don't know if
overriding it like you did really makes sense, since what you're
outputting definitely doesn't fit the standard.


-dave

/*===
House Absolute Consulting
www.houseabsolute.com
===*/

Re: Quick question: fractional seconds

[Tim Bunce]

On Wed, Mar 26, 2003 at 09:54:11AM -0500, John Siracusa wrote:
> On 3/26/03 12:33 AM, Dave Rolsky wrote:
> 
> > But if it's another attribute it needs a precision.  I don't want to call
> > it "fractional seconds" and let each user decide, because that kills
> > inter-operability.
> 
> Fractional seconds can simply be the most general form of the attribute.
> You can then truncate/pad (or round) that value to produce all
> fixed-precision "derived" attributes: milliseconds, nanoseconds, etc.  But
> "fractional seconds" should simply be an integer (or BigInt, if necessary)
> value that comes after the decimal point.  That's the most general
> implementation, and doesn't close any doors for the future, as far as I can
> tell.  You may also think it's the most "useless" implementation, but it'd
> help me, at least :)

Me too.

And it reminds me of this (possibly irrelevant) precedent...

LIBRARY
 Standard C Library (libc, -lc)
 
SYNOPSIS
 #include 
 
 int
 gettimeofday(struct timeval *tp, struct timezone *tzp);
 
 int
 settimeofday(const struct timeval *tp, const struct timezone *tzp);
 
DESCRIPTION
 Note: timezone is no longer used; this information is kept outside the kernel.
 
 The system's notion of the current Greenwich time and the current time
 zone is obtained with the gettimeofday() call, and set with the
 settimeofday() call.  The time is expressed in seconds and microseconds
 since midnight (0 hour), January 1, 1970.  The resolution of the system
 clock is hardware dependent, and the time may be updated continuously or
 in ``ticks''.  If tp or tzp is NULL, the associated time information will
 not be returned or set.
 
 The structures pointed to by tp and tzp are defined in  as:
 
 struct timeval {
 longtv_sec; /* seconds since Jan. 1, 1970 */
 longtv_usec;/* and microseconds */
 };

The gettimeofday interface was designed when microseconds were a
long period, and for system clocks using microseconds is quite reasonable.

For DateTime it seems reasonable to adopt the highest resolution
that'll fit in a 32 bit int.  I think I'm right in saying that's nanoseconds.

Tim.

Re: Request for DateTime API addition: today() constructor

[Joshua Hoblitt]

> > Why not have the constructors take any timezone as an argument?
> >
> > ->now( 'utc' )
> >
> > or
> >
> > ->now( timezone => 'local' )
> >
> > or even
> >
> > ->now( timezone => 'floating' )
> >
> > If no arguments are specified you get still get UTC.
>
> You could, but I like the simplicity and clarity for these common cases.

In this case I don't see why we can't have our constructors and eat them too. :)

-J

--

Re: Request for DateTime API addition: today() constructor

[Tim Bunce]

On Tue, Mar 25, 2003 at 09:42:30AM -1000, Joshua Hoblitt wrote:
> On Tue, 25 Mar 2003, Tim Bunce wrote:
> 
> > On Mon, Mar 24, 2003 at 06:59:17PM -0600, Dave Rolsky wrote:
> > > On Mon, 24 Mar 2003, Joshua Hoblitt wrote:
> > >
> > > > > True. Though it'll be so commonly used I think it deserves a constructor.
> > > >
> > > > Ditto.  It would also be nice if it defaults to current TZ instead of a
> > > > floating time.  The same for ->now.
> > >
> > > Actually, both ->now and ->today default to UTC, because they use
> > > Time::Local::timegm internally.
> >
> > I would regularly need either of those so I think I'd like
> > to see constructors for those four common forms. Perhaps:
> >
> > now_local()
> > now_utc()
> > today_local()
> > today_utc
> 
> Why not have the constructors take any timezone as an argument?
> 
> ->now( 'utc' )
> 
> or
> 
> ->now( timezone => 'local' )
> 
> or even
> 
> ->now( timezone => 'floating' )
> 
> If no arguments are specified you get still get UTC.

You could, but I like the simplicity and clarity for these common cases.

Tim.

ANNOUNCE: DateTime::Calendar::Julian 0.04 and ::Christian 0.01

[Eugene van der Pijll]

I have just uploaded DateTime::Calendar::Julian 0.04 and
DateTime::Calendar::Christian 0.01 to CPAN.

from the ::Julian changelog:

0.04  2003-03-13
- changed output of datetime() to 2000-01-01J00:00:00, to be
  different from Gregorian dates.

- removed bug in day_of_year calculation

- removed "use Params::Validate", which was superfluous after v0.03


(Dave, what is the datetime() method for?  It would be nice if every
Calendar module had at least one output method in common, returning a
compact, calendar-specific representation of the datetime.)


from the ::Christian changelog:

0.01  2003-03-26
- original version (still buggy, probably)

and from the POD:

=head1 BUGS

=over 4

=item * There are problems with calendars switch to Gregorian before 200
AD or after about 4000 AD. Before 200 AD, this switch leads to
duplication of dates. After about 4000 AD, there could be entire missing
months. (The module can handle dates before 200 AD or after 4000 AD just
fine; it's just the calendar reform dates that should be inside these
limits.)

=item * There may be functions that give the wrong results for the year
of the calendar reform. The function L is a known problem. If
you find any more problems, please let me know.


There are still some things I want to add to this module (for example,
I have put in only the 3 most important calendar reform dates; there are
at least 10 times as many), but I didn't want to wait any longer with
the release.

By the way, considering the complexity of this module, I think it was
the correct decision to include only the Gregorian calendar in the core
of DateTime.

Eugene

Re: wroking on the as_set portion of the sunrise module

[Flavio S. Glock]

By the way:
  Altitide --> Altitude

Hill, Ronald wrote:
> What I wanted to accomplish is to have the module accept a
> DateTime::Set object compute the rise/set times and return a new
> DateTime::Set object. Here is what I have done:

> sub as_set {
> my $self = shift;
> my $dt = shift;
> croak( "Dates need to be DateTime::Set objects (" . ref($dt) . ")" )
>   unless ( ref($dt) eq 'DateTime::Set' );
>   my @set = ();
>   my $iter = $dt->iterator;
>   while (my $tmp_dt = $iter->next )  {
> my($tmp_rise,$tmp_set) = sunrise( $self, $tmp_dt);
> push(@set, $tmp_rise);
>   push(@set, $tmp_set);
> }
> return DateTime::Set->new( dates =>[sort @set] );
> 
> }
 

You could build a recurrence:

  sub sunrise_as_set {
my $self = shift;
my $class = ref($self);
return DateTime::Set->new( recurrence => $class::following_sunrise
);
  }

  sub sunset_as_set {
my $self = shift;
my $class = ref($self);
return DateTime::Set->new( recurrence => $class::following_sunset );
  }

Now, since you have rise/set times, you can build a "DateTime::SpanSet",
which is a set of intervals.

We haven't finished the discussion on what is the syntax for creating 
a DateTime::SpanSet, but it would be something like this:

  sub daytime_as_spanset {
my $self = shift;
my $class = ref($self);
my $sunrises = $self->sunrise_as_set;
my $sunsets  = $self->sunset_as_set;
return $sunrises->until( $sunsets );
  }

  sub nighttime_as_spanset {
my $self = shift;
my $class = ref($self);
my $sunrises = $self->sunrise_as_set;
my $sunsets  = $self->sunset_as_set;
return $sunsets->until( $sunrises );
  }

> Having done this, I was able to write a perl script using the easter and
> sunrise
> module like this:

> my $easter_sunday = DateTime::Event::Easter->new();
> 
> my $sunrise = DateTime::Event::Sunrise ->new(
>  Longitude =>'-118' ,
>  Latitude => '33',
> );
> 
> my $dt1 = DateTime->new( year   => 2000,
>  month  => 1,
>  day=> 1,
>   );
> 
> my $dt2 = DateTime->new( year   => 2050,
>  month  => 12,
>  day=> 1,
>   );
> 

  my $dt_span = DateTime::Span->new( begin => $dt1, end => $dt2 );

> my $easter = $easter_sunday->as_set(from=>$dt1, to=>$dt2, inclusive=>1);

  # I would expect $easter_sunday->as_spanset to return 
  # the time from sunday 00:00 until 23:59
  $easter = $easter_sunday->as_spanset->intersection( $dt_span );

> my $set2 = $sunrise->as_set($easter);

  my $set2 = $sunrise->daytime_as_spanset->intersection ( $easter );

> my $iter = $set2->iterator;
> while ( my $dt = $iter->next ) {
> $dt->set_time_zone( 'America/Los_Angeles' );
> print $dt->datetime ."\n";
> }

I think we could just have a 
  $set = $set->time_zone( 'America/Los_Angeles' );
method (but we don't have it yet).

All this might seem a bit strange, but the idea of using sets is that
you don't have to use iterators -- you use set operations instead.
(you can also 'print $set' )

Now show it:

  my $iter = $set2->iterator;
  while ( my $dt = $iter->next ) {
 print $dt->begin->datetime ." until ". $dt->end->datetime ."\n";
  }

Note: I haven't tested all this yet, and some of the syntax is not
implemented.
All suggestions are very welcome.

- Flavio S. Glock

Re: DateTime::Event::Sunrise Beta number 3

[John Peacock]

Hill, Ronald wrote:
No, it is not CVS. This is the way it was in the Astro::Sunrise module
I can't remember where I got it from.
	$VERSION = (qw$Revision: 0.01 $)[1];


Thanks John!! I have changed the module to use this syntax

Except that if you are not using CVS, there is no reason to do it at all.  Just use

	$VERSION = "0.01";

instead; the "$Revision: 9.99 $" stuff is the allow CVS to automatically 
increment the revision when you commit a new version to the repository.  It has 
no functionality at all outside of CVS.

John

--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD  20706
301-459-3366 x.5010
fax 301-429-5748

wroking on the as_set portion of the sunrise module

[Hill, Ronald]

Hi Flavio,

I am working on the as_set portion of the sunrise module and I need your
advise. What I wanted to accomplish is to have the module accept a
DateTime::Set object compute the rise/set times and return a new
DateTime::Set object. Here is what I have done:

sub as_set {
my $self = shift;
my $dt = shift;
croak( "Dates need to be DateTime::Set objects (" . ref($dt) . ")" )
  unless ( ref($dt) eq 'DateTime::Set' );
  my @set = ();
  my $iter = $dt->iterator;
  while (my $tmp_dt = $iter->next )  {
my($tmp_rise,$tmp_set) = sunrise( $self, $tmp_dt);
push(@set, $tmp_rise);
  push(@set, $tmp_set);
}
return DateTime::Set->new( dates =>[sort @set] );

}

Having done this, I was able to write a perl script using the easter and
sunrise
module like this:
#!/usr/bin/perl
use strict;
use warnings;
use DateTime;
use DateTime::Event::Sunrise;
use DateTime::Event::Easter;

my $easter_sunday = DateTime::Event::Easter->new();

my $sunrise = DateTime::Event::Sunrise ->new(
 Longitude =>'-118' ,
 Latitude => '33',
);

my $dt1 = DateTime->new( year   => 2000,
 month  => 1,
 day=> 1,
  );

my $dt2 = DateTime->new( year   => 2050,
 month  => 12,
 day=> 1,
  );


my $easter = $easter_sunday->as_set(from=>$dt1, to=>$dt2, inclusive=>1);

my $set2 = $sunrise->as_set($easter);

my $iter = $set2->iterator;
while ( my $dt = $iter->next ) {
$dt->set_time_zone( 'America/Los_Angeles' );
print $dt->datetime ."\n";
}

Is there anything else I need to add/change?

Please advise.

Thanks

Ron Hill

RE: DateTime::Event::Sunrise Beta number 3

[Hill, Ronald]

> 
> Dave Rolsky wrote:
> > 
> >   $VERSION = qw($Revision: 0.01 $) [1];
> > 
> > That's not CVS, is it?  If it is, please don't use it's 
> revision numbers
> > directly (this is discussed in the dev docs I wrote).

No, it is not CVS. This is the way it was in the Astro::Sunrise module
I can't remember where I got it from.
> 
> And even if Dave hadn't prohibited that mode of operation, 
> the above code is not 
> backwards compatible to 5.005_03, which emulates qw() using 
> split.  This would 
> be correct, though (note the movement of the parens):
> 
>   $VERSION = (qw$Revision: 0.01 $)[1];

Thanks John!! I have changed the module to use this syntax

> 
> although this is even better (IMNSHO):
> 
>   use version;
>   $VERSION = new version qw$Revision: 0.01 $;
> 
> see
> 
>   http://search.cpan.org/author/JPEACOCK/version-0.28/
> 
> John

Re: DateTime::Event::Sunrise Beta number 3

[John Peacock]

Dave Rolsky wrote:
  $VERSION = qw($Revision: 0.01 $) [1];

That's not CVS, is it?  If it is, please don't use it's revision numbers
directly (this is discussed in the dev docs I wrote).
And even if Dave hadn't prohibited that mode of operation, the above code is not 
backwards compatible to 5.005_03, which emulates qw() using split.  This would 
be correct, though (note the movement of the parens):

	$VERSION = (qw$Revision: 0.01 $)[1];

although this is even better (IMNSHO):

use version;
$VERSION = new version qw$Revision: 0.01 $;
see

	http://search.cpan.org/author/JPEACOCK/version-0.28/

John

--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD  20706
301-459-3366 x.5010
fax 301-429-5748

Re: Quick question: fractional seconds

[John Siracusa]

On 3/26/03 12:33 AM, Dave Rolsky wrote:
> On Tue, 25 Mar 2003, John Siracusa wrote:
>> Hrm, well, I'd actually be happy (for my purposes) with simply storing
>> fractional seconds as an integer somewhere.  I don't care if fractional
>> durations are allowed, or if fractional seconds are used in date
>> calculations at all.  I just want fractional seconds to be preserved:
> 
> See, some people think it should be another attribute, other think that
> seconds should be floating point.  Personally, I don't know.

If you mean that seconds should be stored as an actual float, I think that's
obviously the wrong choice due to rounding errors during floating point
math.  Better to actually store the numbers before and after the decimal
point as separate integers (or use a single "BigFloat"-type value that
avoids rounding errors).  But that's just the storage method.  Making a
float_seconds attribute that join('.', ...)s them is fine, whatever :)

> But if it's another attribute it needs a precision.  I don't want to call
> it "fractional seconds" and let each user decide, because that kills
> inter-operability.

Fractional seconds can simply be the most general form of the attribute.
You can then truncate/pad (or round) that value to produce all
fixed-precision "derived" attributes: milliseconds, nanoseconds, etc.  But
"fractional seconds" should simply be an integer (or BigInt, if necessary)
value that comes after the decimal point.  That's the most general
implementation, and doesn't close any doors for the future, as far as I can
tell.  You may also think it's the most "useless" implementation, but it'd
help me, at least :)

I've already got at least two different precisions for fractional seconds,
and I'm perfectly happy to sprintf() or round() for myself as necessary to
help interoperability while I wait for further standardization.  I just need
a place to store fractional seconds.

-John

Re: DT am/pm support?

[Flavio S. Glock]

Joshua Hoblitt wrote:
> 
> > > Is a leap second 12:01pm or 12:01am?
> >
> > It's 11:60pm
> 
> Now that I think about it that makes a lot more sense. :)

11:59:60pm

- Flavio S. Glock

Re: Quick question: fractional seconds

[Flavio S. Glock]

Dave Rolsky wrote:
> See, some people think it should be another attribute, 
> other think that seconds should be floating point.  
> Personally, I don't know. 
> But if it's another attribute it needs a precision.  
> I don't want to call it "fractional seconds" and let 
> each user decide, because that kills inter-operability.

I had that problem in Date::Tie, and I solved it by storing
"integer-seconds"  and "fraction-of-seconds" separately:

  ($int_second, $frac_second) = f( 1234.4567 );
  # $int_second = 1234
  # $frac_second = 0.4567

This way, frac_second if a full-precision real (at least 9 digits),
whatever the value of int_second.
The parser actually splits on /[\.\,]/, such that it works
in many languages (some languages use comma as the separator).

- Flavio S. Glock

Re: ICal and timezones

[Joshua Hoblitt]

> 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

--

Re: ICal and timezones

[Iain 'Spoon' Truskett]

* Joshua Hoblitt ([EMAIL PROTECTED]) [26 Mar 2003 19:07]:
> * Iain Truskett wrote:
[...]
> > +my $rdt = $dt->clone;
> > +$rdt->set_time_zone( 'UTC' );
> > +return $self->format_datetime( $rdt );

> I think this is dangerous... asking for -0600 and getting UTC just
> doesn't seem like the right thing to do. Sticking a warn/cluck in
> there would be much better.

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?

Or should I just wrap the formatter in a 'no warnings;' and have the
code not warn if warnings are off?

Could always have it as an option on new() I suppose, but (Builder
notwithstanding) I've not a fondness for adding lots of options.

Hmm.

I know I'm not going to be happy unless I can have it do it without a
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.

Traditionally, this means forking =) I guess I'll be happy if there's
some way to make it do it, even if it's not the default behaviour.


cheers,
-- 
iain.  

Re: ICal and timezones

[Joshua Hoblitt]

> Index: lib/DateTime/Format/ICal.pm
> ===
> RCS file: 
> /cvsroot/perl-date-time/modules/DateTime-Format-ICal/lib/DateTime/Format/ICal.pm,v
> retrieving revision 1.6
> diff -u -r1.6 ICal.pm
> --- lib/DateTime/Format/ICal.pm   16 Feb 2003 17:23:01 -  1.6
> +++ lib/DateTime/Format/ICal.pm   26 Mar 2003 07:28:47 -
> @@ -131,6 +131,10 @@
>  {
>  return 'TZID=' . $tz->name . ':' . $base;
>  }
> +
> +my $rdt = $dt->clone;
> +$rdt->set_time_zone( 'UTC' );
> +return $self->format_datetime( $rdt );
>  }

I think this is dangerous... asking for -0600 and getting UTC just doesn't seem like 
the right thing to do.  Sticking a warn/cluck in there would be much better.

-J

--