Re: DateTime::Event::Sunset problems
For my 2-cents, returning the time in the same zone of the DT-object you passed in, makes the most sense. If you're focusing on the astronomy, you probably already used UTC. If you don't know UTC from a potted-plant, it will still work right for you. Steve W. Matt Sisk wrote: Hill, Ronald wrote: As for sunrise it's up to the group as to what to do. [see my other post on this] As I said, having the behavior well documented is acceptable to me. From an astronomical caclulation point of view (i.e. using the results for further calculations), you'd expect UTC results. From a "joe user what time will the sun rise" point of view, this might not be the case. Matt
Re: DateTime::Event::Sunset problems
Hill, Ronald wrote: > > Hi Flavio, > > [snipped] > > > I agree. > > > > I think that this is a better way to do it, because it keeps DateTime > > object inheritance and it takes care of 'locale' and other internals: > > > > my $tmp_dt1 = $dt->clone->truncate( to => 'day' ); > > I don't know why, but this will not work:( > I added this and the times that were generated were incorrect Oops. That's my fault. This truncates to current timezone midnight - it's different from the UTC midnight! This is the right way to do it, I think: my $tmp_dt1 = $dt-> clone-> set_time_zone( 'UTC' )-> truncate( to => 'day' ); $tmp_dt1->set_time_zone( $tz ) unless $tz->is_floating; > > > > # $tmp_dt1->set_time_zone( 'UTC' ) > > # if $tmp_dt1->time_zone->is_floating; > > > > my $rise_time = $tmp_dt1 + $rise_dur; > > my $set_time = $tmp_dt1 + $set_dur; > > return ( $rise_time, $set_time ); > > Here is what I ended up doing > > my $rise_time = $tmp_dt1 + $rise_dur; > my $set_time = $tmp_dt1 + $set_dur; > my $tz = $dt->time_zone; > $rise_time->set_time_zone($tz) unless $tz->is_floating; > $set_time->set_time_zone ($tz) unless $tz->is_floating; > return ( $rise_time, $set_time ); That's ok. Maybe you could set the 'locale' too, just in case. However, it does not keep the object class, in case you are not using DateTime. This may be a problem for DT::Calendar::Hebrew and others. - Flavio S. Glock
Re: DateTime::Event::Sunset problems
> [Flavio] > > No, converting from UTC to floating would give the same "unexpected" > > results. > > [Ronald] > I would set the time zone after I have added/subtractd the duration > to get the rise/set times. > As for floating time zones I say leave it at UTC and document > it. I agree. I think that this is a better way to do it, because it keeps DateTime object inheritance and it takes care of 'locale' and other internals: my $tmp_dt1 = $dt->clone->truncate( to => 'day' ); # $tmp_dt1->set_time_zone( 'UTC' ) # if $tmp_dt1->time_zone->is_floating; my $rise_time = $tmp_dt1 + $rise_dur; my $set_time = $tmp_dt1 + $set_dur; return ( $rise_time, $set_time ); How about this: This module understands "floating times" as being at time zone offset 00:00, because there is no such things as floating sunrise or sunset times. - Flavio S. Glock
Re: DateTime::Event::Sunset problems
Hill, Ronald wrote: As for sunrise it's up to the group as to what to do. [see my other post on this] As I said, having the behavior well documented is acceptable to me. From an astronomical caclulation point of view (i.e. using the results for further calculations), you'd expect UTC results. From a "joe user what time will the sun rise" point of view, this might not be the case. Matt
RE: DateTime::Event::Sunset problems
Hi Matt, [snipped] > > My bad! Sorry about that. > > Although, I was referring to *all* event modules, or modules > that return sets, not just DTE::Sunset. I'm not sure if there are any > other modules that drop into UTC mode by default, however. I think this would depend on the function of the module. I took a quick look at the easter module. Rich has: return DateTime->new(year=>$year, month=>$month, day=>$day); notice he is not setting the time zone, not that it matters since it is only year,month, day no need to set the time zone. However, for sunrise/set it matters a great deal since all of the calculations depend on UTC time. As for sunrise it's up to the group as to what to do. [see my other post on this] Thanks Ron Hill
RE: Install Problem with DateTime.pm
Hello, [snipped] > > I'm stumped.. > > I have a problem installing DateTime.pm. I get a LNK1106 & > U1077 with the 'nmake' command. The messages for PERL- V and > 'nmake' are below. I am using Windows XP and VC++ 5 > > I have plenty of available space on my hard drive and there > are no integrity problems. > > I have searched google and found some references to upgrading > to VC++ 6 would solve the problem, but before I spend the > cash, I would like some conformation of that. > > Has anyone encountered this problem before? Got a solution? [much snippage] It seems that you are running the activestate version of perl. The question now is did you install the precomiled version of perl or did you download the source and build perl yourself? If you installed the prebuild version of activestate perl then you need to use the VC++ 6 to build your modules. You can use ppm to install the DateTime modules unfortunately, I have not built them yet [for that version of perl] :( Ron Hill
RE: DateTime::Event::Sunset problems
Hi Flavio & Dave,
>
> Dave Rolsky wrote:
> >
> > On Wed, 24 Sep 2003, Flavio S. Glock wrote:
> >
> > > sub _following_sunrise {
> > > [ ... initialize ...]
> > > my $tz = $dt->time_zone;
> > > my $loc = $dt->locale;
> > > [ ... some calculations ... ]
> > > $tmp_rise->set_time_zone( $tz ); # unless
> $tz->is_floating ???
> > > $tmp_rise->set_locale( $loc );
> > > return $tmp_rise;
> > > }
> >
> > It's probably ok to set the time zone even if the given DT is in the
> > floating time zone.
>
> No, converting from UTC to floating would give the same "unexpected"
> results.
>
> How about adding ( localtime - gmtime ) before converting to floating?
I think we are making this harder that it needs to be. First off,
do you think it would be better to add these things in the _sunrise
subroutine? This is where I have created the new DT object.
my $rise_dur = DateTime::Duration->new( hours => $hour_rise,
minutes => $min_rise);
my $set_dur = DateTime::Duration->new( hours => $hour_set,
minutes => $min_set);
my $tmp_dt1 = DateTime->new(
year => $dt->year,
month => $dt->month,
day => $dt->day,
hour => 0,
minute=> 0,
time_zone => 'UTC'
);
my $rise_time = $tmp_dt1 + $rise_dur;
my $set_time = $tmp_dt1 + $set_dur;
return ( $rise_time, $set_time );
I would set the time zone after I have added/subtractd the duration
to get the rise/set times.
As for floating time zones I say leave it at UTC and document
it.
just my 2 cents!!
Ron Hill
Re: DateTime::Event::Sunset problems
Hill, Ronald wrote in the POD: Returns two DateTime objects sunrise and sunset. Please note that the time zone for these objects is set to UTC. So don't forget to set your timezone!! My bad! Sorry about that. Although, I was referring to *all* event modules, or modules that return sets, not just DTE::Sunset. I'm not sure if there are any other modules that drop into UTC mode by default, however. Matt
Re: DateTime::TimeZone::POSIX
Not that I have seen. This would be tricky to do right. I don't think you can make arbitrary timezones easily. Ideally the "right" thing to do would be to parse the TZ string and find the Olsen entry that matches it, then use the Olsen ID. In the cases where that does not exist, then you would have to make a timezone object up that represents the rules for the TZ. Perhaps you can simply do this each time you parse a TZ... Nonetheless, I think being able to parse TZs would be a great thing for the DT project. -ben On Thu, Sep 25, 2003 at 12:49:00PM +0200, Claus Färber wrote: > Hallo, > > is someone working on a module that takes timezone strings from the > environment variable TZ as defined by POSIX: > http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap08.html > > Claus > -- > http://www.faerber.muc.de
RE: DateTime::Event::Sunset problems
Hi Matt, > > [snipped] > > If not, at least make sure that the module clearly states the > UTC behavior. > > Matt > It does, from the POD See DateTime::Set. =head2 ($sunrise, $sunset) = $sunrise_object->($dt); Internal method. Returns two DateTime objects sunrise and sunset. Please note that the time zone for these objects is set to UTC. So don't forget to set your timezone!! =head1 AUTHOR Ron Hill
DateTime::TimeZone::POSIX
Hallo, is someone working on a module that takes timezone strings from the environment variable TZ as defined by POSIX: http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap08.html Claus -- http://www.faerber.muc.de
DateTime PPM problem
Am trying to install DateTime on Windows platform, Win2k. I have Perl 5.8 build 806 installed, when I try to install DateTime with PPM I get this: PPM> version 2.1.5 PPM> install DateTime Install package 'DateTime?' (y/N): y Installing package 'DateTime'... Error installing package 'DateTime': Read a PPD for 'DateTime', But it is not intended for this build of Perl (MSWin32-x86-multi-thread) Is there anything I can do to fix this?? -- __ / )_/_ It is a capital mistake to theorise before one has data. /--/ __ /Insensibly one begins to twist facts to suit theories, / (_/ (_<__ Instead of theories to suit facts. -- Sherlock Holmes, "A Scandal in Bohemia" Arthur W. Neilson III, WH7N - FISTS #7448 Bank of Hawaii Distributed Systems Services Solaris/HPUX/BSD Development and Support [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: Re: Olson <-> Microsoft mappings
> On Wed, Sep 24, 2003 at 10:54:04AM -0500, Dave Rolsky said: > > You do realize that mapping time zones to countries will take a _lot_ of > > maintenance, right? > > Just as a FWIW ... > > http://blogs.gotdotnet.com/raymondc/PermaLink.aspx/8b23d26b-7e11-425d-b612-13396ef3ec71 It's good to keep this kind of thing in mind. Wouldn't the major city names be less prone to these kinds of disputes? Surely there will be times when some will be disputed but I don't see it happening so often as to be a major problem. One way of handling this might be just to play no favorites and to place cities in whatever catagories (countries) we think people are going to look. So in the case of places like Taiwan and Hong Kong we list them both as part of China and as their own individual coutries. We might include a disclaimer that the catagories are designed to put cities where a large number of people are bound to look and that this should not be construed as a geography lesson. We could list all three of Great Britain and England and Ireland as countries. We should also keep in mind that every mapping will be tied to a particular version of the Olson DB. That version will have a timestamp which can help settle any disputes (it doesn't remove them entirely but avoids disputes brought up after the timestamp). Lastly, I'm for some reason or another not worried if people like the government of India want to ban the use of the DateTime module... It's Open Source, let them distribute their own modified version. Any graphical UIs (like the RH one) will learn to just use a map without borders. Putting the cities at the proper lat/long is the important thing. In the not-so-distant future I see there will be a need to be able to localize these mappings. I see no reason that the mappings need to match from one locale to the next. If some country wants to provide their own local world view I see no reason it can't be released right alongside the others. While I didn't imagine it used for this purpose, this is another example where allowing people to publish modules that others can just "plugin" to get different mappings becomes useful. My $0.02 worth, -- Michael --
