> Has anyone encountered this problem before? Got a solution?
Is upgrading to Perl 5.8.0 an option for you?
-J
--
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 go
Michael and Alice Smith wrote:
>
> I would like to work on a calendar for the DateTime Project.
>
> Is anyone already working on a Chinese calendar?
I was planning to by adapting a Java version I've written, but free time
has been virtually nonexistent this year. Feel free to take it on and,
if
I would like to work on a calendar for the DateTime Project.
Is anyone already working on a Chinese calendar?
> 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.
This is what the Olson DB does.
> Lastly, I'm for some reason or another not worried if people like t
> You do realize that mapping time zones to countries will take a _lot_ of
> maintenance, right?
I agree completely. I don't know many different ways it has to be stated before the
maintenance issues are taken seriously.
> Countries are changing all the time. Think back to the end of the cold
On Wed, 24 Sep 2003, Michael Fair wrote:
> 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.
Yeah, that's why the Olson DB uses continents and cities onl
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_floati
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( $l
Dave Rolsky wrote:
>
> On Wed, 24 Sep 2003, Flavio S. Glock wrote:
>
> > my $sunrise = DateTime::Event::Sunrise->sunrise (
> > longitude =>'-73.59',
> > latitude =>'40.38',
> > altitude => '-0.833',
> > iteration => '1'
> > )->set_time_zone( 'America/New_York' );
>
> I really
On Wed, 24 Sep 2003, Flavio S. Glock wrote:
> This is what it looks like (tested!):
>
> ---
> #!/usr/local/bin/perl
> use DateTime;
> use DateTime::Set 0.1202;
> use DateTime::Event::Sunrise;
>
> my $dt = DateTime->new(
> year => 2003,
> month => 9,
> day=> 24,
> time_zo
This is what it looks like (tested!):
---
#!/usr/local/bin/perl
use DateTime;
use DateTime::Set 0.1202;
use DateTime::Event::Sunrise;
my $dt = DateTime->new(
year => 2003,
month => 9,
day=> 24,
time_zone => 'America/New_York',
);
my $sunrise = DateTime::Event::Sunrise-
On Tue, Sep 23, 2003 at 05:04:22PM -0400, "Steven J. Weinberger" <[EMAIL PROTECTED]>
wrote:
> Just in time for the Hebrew new year (5764, this Friday evening) -
> DateTime-Calendar-Hebrew-0.01.tar.gz has just been uploaded to PAUSE.
>
> Enjoy.
In README.hebrew you mention:
> Understanding the
DateTime-Set 0.1202
- bug fix: when asking for "next" after a set_time_zone or add_duration.
example:
$recurr->add_duration($dur)->next($dt)
returns:
$recurr->next($dt)
- Flavio S. Glock
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
Flavio S. Glock wrote:
>
> > > > Steven J. Weinberger wrote:
> > > > >
> > > > > Sunrise wasn't at 10:42 and the sun will set well before 22:48. Is there
> > > > > something I'm doing wrong?
> > > >
> > > > I think these results are in UTC time.
> > >
> > > Hmm, this should probably be changed so
> > > Steven J. Weinberger wrote:
> > > >
> > > > Sunrise wasn't at 10:42 and the sun will set well before 22:48. Is there
> > > > something I'm doing wrong?
> > >
> > > I think these results are in UTC time.
> >
> > Hmm, this should probably be changed so that the returned object has the
> > same
I also feel that sets should return results with the same time zone as
initially provided with next/prev.
If not, at least make sure that the module clearly states the UTC behavior.
Matt
Dave Rolsky wrote:
You do realize that mapping time zones to countries will take a _lot_ of
maintenance, right?
Countries are changing all the time. Think back to the end of the cold
war, when the USSR dissolved, along with Yugoslavio and Czechoslovakia,
and at the same time E & W Germany became a
Dave Rolsky wrote:
>
> On Wed, 24 Sep 2003, Flavio S. Glock wrote:
>
> > Steven J. Weinberger wrote:
> > >
> > > Sunrise wasn't at 10:42 and the sun will set well before 22:48. Is there
> > > something I'm doing wrong?
> >
> > I think these results are in UTC time.
>
> Hmm, this should probably
On Wed, 24 Sep 2003, Flavio S. Glock wrote:
> Steven J. Weinberger wrote:
> >
> > I'm trying to use DateTime::Event::Sunset in my DateTime::Calendar::Hebrew module,
> > but I'm having a problem. Below is my test code. The
> > results from the code are:
> >
> > 2003-09-24T10:42:00
> > 2003-09-24T2
On Wed, 24 Sep 2003 [EMAIL PROTECTED] wrote:
> This is a bit of a beef I have (as of earlier
> today) with the Olson project. I've managed
> to auto-map about 174 of the olson zones to
> geographic places but am scared I may have to
> do the rest by hand. I wish the names were
> more along the lin
Steven J. Weinberger wrote:
>
> I'm trying to use DateTime::Event::Sunset in my DateTime::Calendar::Hebrew module,
> but I'm having a problem. Below is my test code. The
> results from the code are:
>
> 2003-09-24T10:42:00
> 2003-09-24T22:48:00
>
> Sunrise wasn't at 10:42 and the sun will set w
I'm trying to use DateTime::Event::Sunset in my DateTime::Calendar::Hebrew module, but I'm having a problem. Below is my test code. The
results from the code are:
2003-09-24T10:42:00
2003-09-24T22:48:00
Sunrise wasn't at 10:42 and the sun will set well before 22:48. Is there something I'm doing w
Michael Fair <[EMAIL PROTECTED]> wrote:
> For instance, "So what's the time in Ireland?"
> Do you use "Europe/Dublin" or
"Europe/Belfast"? What's the
> difference?
> Do you expect the end user to know that
Dublin and Belfast are in
> Ireland
> before they can see the time in Ireland?
This is a bi
> "Joshua" == Joshua Hoblitt <[EMAIL PROTECTED]> writes:
Joshua> You have incorrectly attributed that comment to me.
No, he had two chevrons in front of the text. This correctly
attributes it as something you quoted.
Although, it'd be nice if everyone used Emacs supercite instead
of chevron
> On Tue, Sep 23, 2003 at 04:55:02PM -1000, Joshua Hoblitt
<[EMAIL PROTECTED]> wrote:
> > > I gaurantee you there are not 364 timezone/DST rules in use in the
> > > world today. The 364 zones are only needed if you are using dates
> > > in the past, which I'm not. Future timezone changes are a di
Josh,
My deepest apologies for misunderstanding the Alias modules both
times I read it over.
You are totally correct in that Alias is very similar to what I'm
looking for and that like what Ben suggested of using submodules
of Alias I can get what I'm after.
> > UI for end user selection would
> Ok - you have to write a small amount of glue code for your application.
Since I'm not trying to present my users with the full list of 364 zone
names
I expect to need to do some filtering and maintenance.
I started out with the idea that "You know, most applications probably
don't need to pres
29 matches
Mail list logo
