Edmund von der Burg schreef:
2009/1/20 Lyle webmas...@cosmicperl.com:
I've been working on a membership system, letting users select their
timezone when the signup.
...
'all_names' should return all that you need.
Actually, it probably returns more than you want. There are hundreds of
Dave Rolsky schreef:
On Tue, 20 Jan 2009, Eugene van der Pijll wrote:
It may be useful if these kinds of lists were packaged and put on
CPAN; maybe I'll do that at some time.
If you generated this list programmatically, it'd be better to include it
in DateTime::TimeZone, since the list
Randy J. Ray schreef:
In fact, since I'm really just after the short names for the sake of
pretty-printing dates for end-users who aren't impressed by -08:00
where they'd expect PDT, I can use any of the matching zones. It
just seems a waste to have to iterate over the whole set to get the
[EMAIL PROTECTED] schreef:
Here's my first shot at a script. It combines Zefram's suggestion to
use $dt-epoch() and Eugene's recommendation to measure the intervals
at noon instead of at midnight. Next, I'd like to refactor it
using...um...I'm not sure, but something other than $dt-epoch().
I
Zefram schreef:
It ought to be possible to do the interval calculation using
DateTime::Duration instead of -epoch, but the behaviour of DT::D is
unreasonably confusing and I couldn't get it to work. (Strangely, I got
a version that worked fine for America/New_York, where all the days are
[EMAIL PROTECTED] schreef:
I want to iterate the time zones of the world to generate a report of
all days that aren't exactly 24 hours. I want to handle
America/Caracas and America/Sao_Paulo correctly. You mentioned
2007-12-09 was 24.5 hours long in Venezuela. This is precisely the
kind of
Zefram schreef:
Kristian Flint wrote:
definitely a fixed number of seconds in a day
Leap seconds. DateTime doesn't really do them correctly -- actually its
time scale is a bit schizophrenic at the sub-second level -- but it does
represent leap seconds that it knows about. So some days,
Monty, James T schreef:
Leap seconds. DateTime doesn't really do them correctly
Please explain this. I've always thought DateTime *does* handle leap
seconds correctly.
DateTime handles them correctly for dates between the introduction of
leap seconds (1972) and the first yet-to-be-announced
Dave Rolsky schreef:
The problem is that CET could map to many, many different time zones
including Europe/Paris, Europe/Vienna, Europe/Tirane, and many more.
No, CET is unambiguously UTC +1, and therefore not equal to any of those
zones.
Eugene
Zefram schreef:
Sounds like you're looking for the equinox and solstice dates. I don't
see any CPAN module providing this, on search.cpan.org.
Take a look at the DateTime::Util::Astro modules. solar_longitude_before
and _after are useful to look for equinoxes and solstices, but you don't
need
Zefram schreef:
If you want three names, how about
prev_observance_start_for_datetime
this_observance_start_for_datetime
next_observance_start_for_datetime
Datetime just means one point in time; it is not something that is
observed. And these names are awfully long.
What
Anthony R. J. Ball schreef:
I guess maybe is_dst_change might be necessary in that case.
You can make such a function even more useful if you rename it
offset_change: returns the offset change at that datetime in seconds;
returns 0 if no dst change (obviously).
That would give a reasonably
Zefram schreef:
It also explicitly lists some that are based on GMT: the European Union,
I don't think this is actually true. The page quotes a European
directive on summer time. Directives of the European Union are published
in all official languages of the EU, and all of the versions are
Zefram schreef:
I note that DT::TZ::TAI
attempts to treat TAI as a timezone, which doesn't work 100% but does
put TAI in roughly the right relationship to the other DT objects.
As you say, TZ::TAI does not work 100% prefectly. It has turned
out to be impossible to implement it correctly,
Zefram schreef:
So *legally speaking* the standard time in the UK is based on what we
now call UT1. It is an astronomical timescale.
I've read some of the relevant parliamentary debates now, and you're
right. That still doesn't mean that our TZ Europe/London should be based
on UT1: the time
Garrett, Philip (MAN-Corporate) schreef:
McKervey, Nathaniel wrote:
I would like to use your perl module DateTime, but cannot find any
copyright or license information. Can you tell me the terms of use?
For example most modules state
From the DateTime documentation
snip
As this mail was
Todd W schreef:
I was (only kind of) expecting the program below to have this output:
$ perl time.pl
Mon Aug 28 2006 12:00 pm PDT
Wed Aug 30 2006 12:00 pm PST
Will someone please explain why this is the output (Note PDT for the date
that does not fall within PDT)? Is there a document
Zefram schreef:
Joshua Hoblitt wrote:
Is all that stuff just a reinvention of the wheel?
Yes, but this time it's round.
DateTime's wheels are round as well; it's just that there's a whole lot
of machinery attached to the wheels which you may not care for. If there
is any instance where
Zefram schreef:
Eugene van der Pijll wrote:
is any instance where DateTime gets it wrong, please let us know.
There's leap seconds, but I presume that's intentional. AFAIK DateTime
operates correctly within its designed limits.
Leap seconds are one of the things DateTime tries to get right
Zefram schreef:
There are two fundamental problems with DateTime's handling of leap
seconds: one pertaining to the future, and one pertaining to the past.
For every future leap second, there will be a version of DT that
handles it correctly. That the current implementation can not, is only
an
Zefram schreef:
The only reason DateTime.pm (the module) seems to be the fundamental
class of DateTime (the project) is the name; it has no central role,
although there are a number of modules (e.g. formatting modules) that
have been written especially for DT.pm, because it is the most
Jason Thaxter schreef:
Curiosity got the better of me. The fix works and is demonstrated below.
Thank you!
I have just uploaded version 0.10 of the package to CPAN.
Eugene van der Pijll
Heiko Klein schreef:
The DateTime module allows handling of a large range of dates, much
larger than the standard unix epoch (from ~1901 to ~2038). This is
really nice. But when calling the DateTime-from_epoch(epoch = 2**31)
gives not 2038 as I hoped for, but 1901 due to an internal call to
Dave Rolsky schreef:
But in fact, one hour less than 6 months has passed because of the DST
change
I think this is a very strange thing to say, as the duration 6 months
is never a fixed amount of hours, not even in UTC.
In this case, we added 6 months to the _UTC_ time and the displayed
John Siracusa schreef:
Any chance of the great dates without times vs. datetimes split happening
in DateTime for Perl 5? That'd solve a lot of problems too. Maybe some of
the DateTime::Incomplete stuff could help here?
Dave, are you working on this for Perl 5? I've thought about this as
Dave Rolsky schreef:
There have been several reports, they're in the list archives. One was
from Mike Schilli. Then another more recent one complained about the
change I made based on Mike's bug report. Can't win ;)
I've found it now: http://www.nntp.perl.org/group/perl.datetime/5619 .
Dave Rolsky schreef:
http://www.post-gazette.com/pg/05210/545823.stm
Unfortunately it wouldn't make DT.pm any simpler, since we'd still have
the existing leap seconds to account for.
And we'd have to implement leap hours in UTC... (Though not for a couple
of hundred years, so you might just
Mark Fox schreef:
time_zone = 'America/Edmonton');
That's the problem.
2004-10-31T01:03:09 = 1099209789
2004-10-31T01:03:09 = 1099206189
It's during the switch from DST to normal time. Because of DST, times in
local timezones are not guaranteed to be unique.
... for my
purposes I
[EMAIL PROTECTED] schreef:
I was wondering if DateTime has a method for converting rata die (in
particular rd seconds) to a gregorian date? I've done a bit of digging,
but I'm not finding one, only methods for going G - RD.
If not, does anyone have a handy wodge of Perl lying around to do
Dave Rolsky schreef:
Anyway, enjoy ...
0.232004-12-09 (the oh how I hate leap seconds release)
Dave, I don't really know how to tell you, but...
use DateTime;
print DateTime $DateTime::VERSION\n;
$dt = DateTime-new(year = 1997, month = 7, day = 1,
Dave Rolsky schreef:
Grr. I think I know what this is, and fixing it shouldn't be too hard.
Look for a 0.24 sometime soon.
Great!
I've found one other problem, which may be related:
$dt = DateTime-new(year = 1997, month = 6, day = 30,
hour = 23, minute = 59,
I have just released version 0.00_01 of DateTime::TimeZone::TAI to CPAN.
This module implements International Atomic Time (TAI) as a timezone.
TAI is a time scale similar to UTC (Greenwich time), but without the
leap seconds.
Couple of remarks:
- Thank you Dave, for fixing those bugs in
Alberto Manuel Brandao Simoes schreef:
First, send any answer CC to me, given that I am not in the mailing list.
Is there anyway DateTime can guess a date format? I'm processing RSS
files and, unfortunately, they are not coherent in the datetime they use.
The best module for guessing
Eugene van der Pijll schreef:
Thank you, I'll add this to the next version of the package.
... which has now been released: DateTime-Format-Epoch-0.08.
It now supports the ActiveDirectory epoch, and several day counts, such
as Julian Days.
Maybe I'll make the unit parameter in the constructor
Andrew Sterling Hanenkamp schreef:
Just a suggestion for improvement to Eugene van der Pijll's nifty
DateTime::Format::Epoch module. Inside of ActiveDirectory, it uses the
same interval (100-nanos) as .NET, but the epoch base is January 1,
1601 UTC, rather than January 1, A.D. 1.
Andrew Sterling Hanenkamp schreef:
my $ad_date_format = DateTime::Format::Epoch-new(
epoch = $epoch, unit = 1e7, type = 'bigint', skip_leap_seconds
= 1,
local_epoch = undef);
Just a small question: are you sure that the Active Directory count is
in UTC? The DotNet count is in local
There's a bug somewhere in the interaction between leap seconds and time
zones.
In timezones with a positive offset, datetimes after local midnight but
before UTC midnight already are affected by the leap second:
$dt = DateTime-new( year = 1997, month = 7, day = 1,
Are you prepared to make a new release soon? Josh checked in the changes
for DateTime.pm and I'm ready to release it.
I'm not able to release a new version soon. I'm in the middle of a move now.
It will take a few weeks before I have internet access at home.
I wouldn't hold up the new
On Mon, 19 Jul 2004, Eugene van der Pijll wrote:
UTC was not defined before 1972-01-01. In DateTime, utc is used as
time
zone before 1972. The behaviour of our utc before 1972 is undefined,
and
it's perfectly possible to have a leap second 1971-12-31T23:59:60.
Except that UTC
I'm having an itch to convert UTC-TAI. I started off writing this a
DateTime::Format module because the conversion is so simple but since TAI
isn't just a display formating of the Gregorian/UTC system (different
epoch, no
leapseconds, etc.) I'm now thinking this should be DateTime::Calendar
DateTime::LeapSecond claims that there have been 23 leap-seconds since the
start of UTC. This is _incorrect_. There have been only 22 leap-seconds
in the history of UTC. This error is introduced on be the addition of a
leap-second on 1972-01-01. That is the date when the delta been UTC-TAI
Yitzchak Scott-Thoennes wrote:
You could go through the comments in the Olson files; they will say
where the timezones apply, and you should be able to come up with a
pretty good state/nation-timezone table. (If you do this, please
post it here.) For some of the U.S. states, it is helpful to
Dave Rolsky wrote:
- When given mixed positive negative arguments, DateTime::Duration
no longer forces all arguments to be negative.
- For mixed durations, the is_positive, is_zero, and is_negative
methods all return false.
Is it possible to detect mixed durations other than checking all
Eugene van der Pijll schreef:
use DateTime::Format::Epoch::DotNet;
my $formatter = DateTime::Format::Epoch::DotNet-new();
my $dt2 = DateTime-new( year = 100, month = 1, day = 1 );
print $formatter-format_datetime( $dt2 ), \n;
I've just released DT::F::Epoch v0.06
Todd Lorenz schreef:
Could someone kindly confirm/debunk this?
Confirmed. It seems that this is a memory leak in
Params::Validate::validate(), possibly connected to optional parameters.
This:
perl -MDateTime -e'while(1){DateTime-new(year=2003)}'
does not leak; this:
perl -MDateTime
Rick Measham schreef:
I just installed Bundle::DateTime on my Darwin machine ... I hadn't
looked through the docs beforehand :)
Can I suggest two other bundles that I'm willing to maintain (they
shouldn't need much alteration anyway. Not like the full bundle!)
Bundle::DateTime::Minimal
Dave Rolsky schreef:
On Wed, 22 Oct 2003, Eugene van der Pijll wrote:
DT prereq's:
Class::Factory::Util 1.3 - prereq's of DateTime
Params::Validate 0.52
Test::More 0
Time::Local 1.04
Class::Singleton 1.03 - prereq of DT::TimeZone
DateTime::Locale 0.03
Bill McCormick schreef:
I have a duration $dur = $dt_end - $dt_start and I would like to know how
many total weeks and/or days are in this span. How can that be easily
accomplished?
I pretty sure I'll run into leap year issues if I say ...
$weeks = ($dur-months * 4) + 1
Not only
Dave Rolsky schreef:
On Fri, 3 Oct 2003, Eugene van der Pijll wrote:
$dt1-subtract_datetime( $dt2,
[ 'months', 'days', 'minutes', 'seconds' ] );
It's not hard, just a little bit of math. I'm more concerned with the
API. I don't like the one you have
Jonathan Leffler schreef:
Is the DateTime::Calendar::Pataphysical v0.02 module still broken, or
is my build environment somehow broken?
DT::Cal::Pataphysical is broken: it still uses the old DT::Language
system, not the new DT::Locale. This dates from DateTime v0.14
(2003-07-23).
I had not
Jonathan Leffler schreef:
Thanks for the prompt response - I'll wait (it is not critical).
The only thing you have to wait for is for your favorite CPAN server to
update; DT::Cal::Pataphysical v0.03, the Saint Lazare (station) release,
has escaped into the wild half an hour ago.
Eugene
Hill, Ronald schreef:
I wanted to ask the group about an idea I have for an article for the
perl review. This would be a beginner/newbie article on basic usage
of DateTime. I have put together some ideas starting with getting things
into/out of DateTime and comparing dates. Any other ideas for
Joshua Hoblitt schreef:
What you want is to normalize the values of a duration relative to
some fixed point in time. I agree this is something that we need to
do. Patches are welcome. :)
So if I read this correctly the answer is at this time what I'm after
is not possible with
Matt Sisk schreef:
At some point there was discussion of a Hijri calendar on this mailing
list, but I'll be darned if I can find the references.
Are you sure? I can't find any discussion (googling on e.g. islamic
perl datetime finds only one or two posts), and I can't find anything in
my
John Siracusa schreef:
Okay, here's a simple implementation of a memoized
DateTime::Locale::load().
A solution that is more or less equivalent, is to change the
DefaultLocale routine. At the moment, $DefaultLocale is saved as a
string; every time DT::new() is called without a locale argument,
Iain Truskett schreef dat Nick Ing-Simmons schreef:
Does anyone know of a machine-readable map that can convert lat/lon
to timezone?
There has been some discussion about this on the Olson db mailing list.
The archive of this list can be downloaded from
ftp://elsie.nci.nih.gov/pub/ . You can
I've encountered a bug in DT::Infinite math. It seems that adding a
number of days to DT::Infinite::Future results in a DT::I::Future object
again, but adding a number of years changes it.
For example:
my $dt = DateTime-now;
my $dt_inf = DateTime::Infinite::Future-new;
print
Dan Sully schreef:
To get the beginning and ending times of a month:
2002-12-01 00:00:00
2002-12-31 23:59:59
How would one do this with = 0.13 releases?
TIMTOWTDI:
my $dt2 = DateTime-new( month = $month, year = 2002)
-add( months = 1 )
Flavio S. Glock schreef:
First release of DateTime::Incomplete !
http://www.ipct.pucrs.br/flavio/perl/DateTime-Incomplete-0.00_01.tar.gz
It is incomplete, of course.
Very much so...
I would prefer if this:
DateTime::Incomplete-new( year = 2003 );
would create the incomplete dt
Bruce Van Allen schreef:
Some may have seen the news that debate has flared up regarding the
continued use of leap seconds. I don't know whether it will be
resolved soon, so it seemed best to simply acknowledge the issue, and
hope we remember to update the FAQ if something radically changes.
Joshua Hoblitt schreef:
Well, there are only two modules: DT::F::MySQL and DT::F::Pg.
I'd really like to see a lot more database formatters.
snip 10 other databases
Do all of these have different datetime formats? If database X has the
same formats as e.g. Pg, it doesn't need a separate
Claus F?rber schreef:
Rick Measham [EMAIL PROTECTED] schrieb/wrote:
It's in the year 3 A.D. Period. This is a 'simple' module so I don't
think it should try bending user input too much. If you assume it to be
2003, then how do I say it's the year 3?
02/11/0003
Nope. With that input,
Joshua Hoblitt schreef:
Do all of these have different datetime formats? If database X has the
same formats as e.g. Pg, it doesn't need a separate format. Of course
DT::F::DBI should know about these cases.
If X has identical date/time handling as Pg I'd like to see DT::F::X
be isa
Joshua Hoblitt schreef:
Infinite dates do not exist. (And neither do undefined ones.)
If you accept that as dates or not, they are both valid pieces of
information that need to be expressed.
Sure. If the programmer chooses to, by choosing modules that return
them.
But no part of DateTime,
John Siracusa schreef:
On 7/16/03 3:39 PM, Eugene van der Pijll wrote:
Infinite dates do not exist.
Infinite DateTime objects do, which was my point.
The Loch Ness monster exists. That doesn't mean that
DateTime::Format::Roman should accept it.
A Format object does not have to accept
John Peacock schreef:
Given the date 02/11/03 in the locale en_US (so you can assume m/d/y),
what year is that in?
3.
Add the following code (modulo what you called the year variable):
if (length($yr) 4)
warn (Your year value is indeterminant. Performing SWAG[1]!);
Why are years
Dave Rolsky schreef:
On Tue, 15 Jul 2003, Ben Bennett wrote:
200210131:02
No! Egads :-) Actually I wasn't accepting the form 200210130102
either (I will accept 20021013T0102). Should I?
Is the former form unambiguous? If so, you mighta s well accept it.
200210131:02 is
John Siracusa schreef:
All the various DateTime::Format::* modules are nice, but I've been
thinking that it would be even nicer if DateTime had some sort of
rudimentary parsing built in.
I agree with this; the DateTime constructor tends to get a little
verbose. However, I don't quite agree
Flavio S. Glock schreef:
- DateTime::Calendar::RataDie::Duration
a common duration object to compare dates between calendars
An DT::C::RD::Duration would probably look like a DT::Duration object,
but only containing days. Durations in hours, minutes and seconds can be
converted to
Dave Rolsky schreef:
Here's the thing. Yes, the object would contain more precision than the
original data, _but_ presumably if you are only exchanging year and
month data, then you will only look at the year and month of the returned
object.
It's really hard for me to think of a case
Peter J. Acklam schreef:
It is the IERS (http://www.iers.org) who decides when leap seconds
are inserted. According to their page
http://www.iers.org/iers/earth/rotation/utc/table1.html
the first leap second after 1970 was the second before 1972-07-01
00:00:00 UTC.
There cannot have
Ben Bennett schreef:
I was under the impression that the Pataphysical calendar was
basically a fictional one that parodies the French Catholic calendar
(http://user.icx.net/~richmond/rsr/pataphysique/pataphysique.html).
Are you suggesting that it is useful for business calculations?
The
Peter J. Acklam schreef:
And you say that Perl is usually using UTC. Then please show me
some examples of Perl giving the following, which would be correct
for an UTC clock. Actually, just one example would be nice.
$ perl -wle 'print scalar gmtime $_ for 78796799 .. 78796801'
Fri
Rick Measham schreef:
In his question, he assumes that each period (night/day) should be
evenly divided into 12 parts. However this stinks to me! Surely in
the middle of winter, the hour before sunrise shouldn't be a heap
longer than the hour after? Surely the lengths of hours should slowly
John Peacock schreef:
Peter J. Acklam wrote:
I don't see what the epoch has got to do with it. The TAI time
system is exactly like UTC except for the leap seconds, and that,
to me, seems very similar to what Perl is using.
The epoch has everything to do with it. TAI is not defined to
Ahmad Anvari schreef:
I would suggest registering DateTime::Calendar::Jalali
for now.
If that's what most potential users would recognize, it's the right
name. I wouldn't have recognized it, but I'm not the intended audience.
(But I'll install it anyway...)
Eugene
Flavio S. Glock schreef:
The first step would be to write to [EMAIL PROTECTED],
in order to register your calendar in the
DateTime namespace.
It would probably be named DateTime::Calendar::Jalali.
It looks like the Jalali calendar is also called the Persian calendar,
so
Richard Evans schreef:
Does anyone see a pressing need for supporting ISO 639-2 language codes in
DateTime::Locale?
Hey, why not?
I can't see a great need for this, since ISO 639-1 is already fully
supported, but I'm open to comments; please don't just say Hey, why not
though - I don't want
Richard Evans' mail about his Locale modules reminden me of something:
I'm thinking of adding a module for Latin, either DT::Language or
DT::Locale (depending on the release date of Rich's modules). And of
course I want the grammar to be correct, so the month_name() method and
the %B strftime
Someone, possibly Sam Vilain wrote:
against the module. I really would like to remove my dependancy on
Date::Manip, but, really - 4.5MB?
The generated TimeZone modules are a bit larger than they could be. With
the attached patch, their total size is reduced by almost 50%.
(There's an
Dave Rolsky schreef:
On Fri, 6 Jun 2003, Eugene van der Pijll wrote:
The generated TimeZone modules are a bit larger than they could be. With
the attached patch, their total size is reduced by almost 50%.
Can you resend this as a unified diff (-u)? I can't read the other kind
very
Dave Rolsky schreef:
On Thu, 29 May 2003, Rick Measham wrote:
The behaviour now remains the same, however if you set
$DateTime::Format::StrpTime::CROAK to false, methods will
return undef rather than croaking.
Joshua Hoblitt schreef:
When converting a DateTime::Duration month to days - how many days
should it be considering equivalent too? 30? 30.4? 31?
If you want to do this, you have to take into account that a duration of
$x years is translated to 12*$x years internally. If your calendar has
no
Jean Forget schreef:
Will your module contain the names of the days? Like 'Brocoli' (12
Pluviose) or 'Pomme de terre' (22 Vendemiaire)?
My module will support brocoli for 12 Pluvi?se, but I am not so
sure about Pomme de terre. My source (Agenda r?publicain 197)
tells me that Pomme de terre
Joshua Hoblitt schreef:
- when from_object is used should the value for seconds returned by
utc_rd_values be stored then returned by the object itself? This
would allow chaining of calendars without a loss of precision.
Best would probably be te either use Mayan time (if it is known
(probably
Joshua Hoblitt schreef:
This would also solve the following problem:
$d = DateTime-new( year = 2003, month = 4, day= 3,
hour = 0,minute = 0, second = 0 );
$md = DateTime::Calendar::Mayan-from_object( object = $d );
print $md-date, \n; #
Joshua Hoblitt schreef:
Wrong answer #2:
print DateTime::Calendar::Mayan-from_object(
object = DateTime-now(time_zone = 'Europe/Amsterdam') );
So you are proposing something like this?
print DateTime::Calendar::Mayan-now( timezone = 'Europe/Amsterdam' )-date;
Either
Dave Rolsky schreef:
On Thu, 3 Apr 2003, Eugene van der Pijll wrote:
And this works. But even more people will use DateTime-now. And then
a floating time would be wrong.
Why would a floating time be wrong then?
(I think I meant to say 'a utc time', as now() returns a 'utc' time.
However
Joshua Hoblitt schreef:
I got a copy of Calendrical Calculations yesterday and have just about
finished the Mayan/Long count calendar. Should the Haab and Tzolkin
calendars be in the same module (ick!)
I'd think so. You can't really have a separate Haab calendar, as a Haab
date contains only
Dave Rolsky schreef:
On Wed, 2 Apr 2003, Jean Forget wrote:
For the moment, there are two sets of accessors:
- hour, min, second, etc for sexagesimal time
- dhour, dmin and dsecond for decimal time
IMHO, this is the way to go.
but strftime knows only decimal time.
I think it should,
Flavio S. Glock schreef:
In module: DateTime
New method: extend()
Returns a DateTime::Span after the current date.
I don't really like this in DateTime. I feel this functionality belongs
in DateTime::Span. After all, this method is a DateTime::Span
constructor.
Secondly, I don't think the
Rick Measham schreef:
This makes me think .. should there be a way to 'force' a DST change?
For example:
$dst_on = DateTime-new([1am this morning]);
$dt = DateTime-new(year=, month=xx, day=xx,
timezone='Europe/London', dst_on=$dst_on, dst_off=$dst_off);
This would be better handled
I've just put this new module on CPAN:
DateTime::Calendar::Pataphysical 0.01, the Hand of Glory release
It implements the pataphysical calendar. This calendar is much more
regular than the Gregorian calendar, containing 13 months of equal
length (29 days each), and is therefore very easy to
Rick Measham schreef:
Attached is what I hope to be the last beta of the Easter Event
module. I've poked it with sticks like years with no Orthodox Easter
(35000).
I'd like to make it run faster some time, so if anyone can think of
better ways to do things without the Caching problem,
Daniel Yacob schreef:
I favor the first option, but then I also favor Gregorian:: as a name
space and no default calendar system being assumed... ;-)
Unfortunately, us kalandariophiles are a minority on this list; I
suspect Dave in particular of wanting to use DateTime for all kinds of
worldy,
Rick Measham schreef:
Best solution would perhaps to convert to Julian at the start of those
methods, and to convert them back to Gregorian at the end.
(DateTime::Calendar::Julian could be useful here ;-)
Yeah, I figured I might have to do that, although then rather than finding
the
Rick Measham schreef:
Can't use a block eval for 'use X'. All 'use X' commands are parsed before
anything else, so it will always try to use X, even if we don't go there.
Yes, of course, stupid me.
'require X' happens at run-time so doesn't need to be eval-ed.
Except if you want to catch the
Tim Allwine schreef:
I was wondering if you would consider making a fundamental
addition to DateTime. It would be to add the 'quarter' and
'day_of_quarter' to DateTime.
RGH! Please no! 'week' and 'day_of_year' were two of the hardest
methods to write in DT::C::Christian, and now you
Rick Measham schreef:
Beta 2 includes support for Orthodox Easter, however I doubt it
handles it the best way possible. Please take a look and offer
suggestions (its the last sub before the POD). It should also be
noted that both Easters should return Gregorian Dates as they do now.
The
Rick Measham schreef:
They're always around the same time as the western Easter, the
Equinox doesn't change .. its still on Gregorian March 21st (or if
they observe the astronomical equinox they *might* observe March
22nd), and they get the next Astronomical full moon after that which
1 - 100 of 109 matches
Mail list logo
