Looking for help
help
Re: DateTime fraction year
For my needs just getting things right to a day level is all I needed. But, I could see something more accurate as being useful for other situations. But to be honest I’m not really that aware of the details of how leap seconds come into play. But, I expect someone with a better understanding of that sort of stuff could probably come up with a better set of devisers based on seconds rather than days. With just a little digging I think you would have to properly determine one of the following devisors: standard year = 31536000 seconds standard leap year = 31622400 seconds For all the leap seconds you need some sort of map table of some sort (I’m guessing datetime has this some place internally but I don’t see any api to ask it for is_leap_sec_year and I”m not sure that by it self would be meaning full given what was done in 1972): http://www.ietf.org/timezones/data/leap-seconds.list http://www.ietf.org/timezones/data/leap-seconds.list But generally: standard year plus leap second = 31536001 standard leap year plus leap second = 31622401 Special care has to be taken for the above depending on when the leap second exactly occurred and what your dates are. 1972 (if I understand the above link right) is a very special case and could potentially need other possible divisors 31536010, 31536011, 31622410 or 31622411 it depends on exactly how your dates fell out to know which is exactly accurate for a particular set of dates. Then if you could workout delta_seconds between the two dates minus the years (that accounted for leap_years, leap_seconds and timezones) you might be able to get something accurate to that level (but not sure it is possible from what I can tell we can only get to delta_ms which is minutes and seconds and if my reading is right we have no reliable way to convert duration minutes to seconds and delta_ms doesn’t mention anything about timezone so that would take some experimentation to determine if it deals with that). I think technically it is doable just not clear to me how to get at the things needed with current DateTime API’s. Matthew On Jul 4, 2015, at 8:38 PM, Eric Brine ikeg...@adaelis.com wrote: On Fri, Jul 3, 2015 at 12:27 PM, matt...@jenika.com mailto:matt...@jenika.com wrote: I have a need to compute a year with fraction between two dates. Meaning date 1 = 2005-05-04 date 2 = 2015-05-06 then the year I’m after is 10.0054794520548. My thinking on the above is neither 2005 or 2015 is a leap year so I should use a devisor of 365 days and the number of days extra between the above two dates is 2 so 2/365 is 0.0054794520548. Based on the above thinking I need to determine two things to do the above generically. 1) what devisor to use 365 or 366 (depends on if either the start or end year is a leap year) 2) exactly how many days exist between the start date and end date minus all the extra years. What about the number of hours in the day? That varies for some days in many time zones.
Re: Error with the leap year
On Fri, Mar 02, 2012 at 10:17:08AM +, Zefram wrote: In the awkward case, it advances to March 1st: ... Of course, it has the downside that year addition isn't associative: advancing from a February 29th by four years gives a different result from advancing by one year four times. ... It's nicer, in that day addition *is* associative. Of course, a quarter of the time (when the 365 days spans a leap day), the 365-days-later won't be the same-date-next-year. Is that what you mean by the leap year problem? Reasons Why You Should Never Write Custom Date / Time Handling Code Yourself Vol. 1 No. 1 - 3... Matthew
Re: datetime question
On Sunday, October 31, 2010 15:26:04 Guustaaf Damave wrote: Is there a way to retrieve the next switchover time for a time zone? I could then store that in the cache and stop using that cache entry after that time, similar to how web browsers do that. Your best bet is probably finding a way to query the TZ database directly to get this information. The C library calls don't directly support looking up the switchover so this might not be real easy to do. You can probably pull up the data from the raw or compiled zoneinfo files. http://en.wikipedia.org/wiki/Tz_database Some APIs exist for this in DateTime: http://search.cpan.org/dist/DateTime- TimeZone/lib/DateTime/TimeZone/OlsonDB.pm But one of the sentences in the docs says: USAGE-- Not yet documented. This stuff is a mess. Thanks again! Best regards, Guustaaf Regards, Matthew Hall
DateTime::Format::Strptime bug report
Hello all,
I am trying to parse BSD Syslog format time stamps, like this one:
Sep 1 05:39:02
Using the DateTime::Format::Strptime class, the call is failing with
the following result, when I use the format string '%b %d %H:%M:%S'.
There is no use providing a month name (Sep) without providing a year.
at /homes/megahall/workspace/montage/src/Yahoo/Montage/WelfParser.pm line 55
Searching for the error on the Internet even with the (Sep) removed
does not return any meaningful results.
I am wondering what I can do to fix this issue so I can get DateTime
working, or if there is a workaround of some sort. It does not seem
reasonable to croak or return undef time object because then there is
no way to set a valid year using a member function plus some external
year logic.
In addition, when trying to debug using the default on_error undef
setup, I discovered it is not possible to see this error message, and
that the $object-errstr() method mentioned in the documentation does
not seem to exist. Grepping the perl lib folder did not reveal it
either and I got an error trying to call it as well.
Further information below.
Thanks,
Matthew.
In the grep output; only a documentation passage is mentioned. This is
the passage from the documentation:
This is the default behavior. The module will return undef whenever it
gets upset. The error can be accessed using the $object-errstr method.
This is the ideal behaviour for interactive use where a user might
provide an illegal pattern or a date that doesn't match the pattern.
Here are my package versions.
DateTime-Format-Builder-0.7901_02
DateTime-Format-Epoch-0.10_01
DateTime-Format-ISO8601-0.0601_01
DateTime-Format-Strptime-1.0702_02
DateTime-Locale-0.42_01
DateTime-TimeZone-1.01_01
DateTime-0.5000_01
Here is a code snippet.
my @date_time_formats = (
# BSD: 'Mmm DD HH:MM:SS'
['BSD Syslog' , new DateTime::Format::Strptime(pattern = '%b %d
%H:%M:%S' , locale = 'en_US', time_zone = 'GMT', diagnostic =
$diagnostic, on_error = 'croak')],
);
sub welf_time {
my ($time_str) = @_;
$log-debug(process time_str [$time_str]);
my $date_time;
my $type;
my $parser;
for (my $i = 0; $i scalar(@date_time_formats); $i++) {
eval {
$type = $date_time_formats[$i][0];
$parser = $date_time_formats[$i][1];
$log-trace(call parser [$type]);
$date_time = $parser-parse_datetime($time_str);
$log-trace(return parser [$type] result [ . display($date_time)
. ] errstr [ . display($parser-errstr()) . ]);
};
if ($@) {
$log-info(parser [$type] experienced exception {...@}\n);
}
}
$log-log(!defined($date_time)? $WARN : $TRACE,
processed time_str [$time_str] into date_time [ . display($date_time)
. ]);
if (!defined($date_time)) {
$date_time = DateTime-now();
}
return $date_time-epoch();
}
Below is the log4perl output, along with diagnostic enabled on the
parser.
[2010/09/01 20:06:30] [WelfParser.pm:44] [DEBUG]
process time_str [Sep 1 05:39:02]
[2010/09/01 20:06:30] [WelfParser.pm:53] [TRACE]
call parser [BSD Syslog]
Entered = Sep 1 05:39:02
Parser = ($month_name, $day, $hour_24, $minute, $second) =
$time_string =~ /(\S+) ([\d ]?\d) ([\d ]?\d):([\d ]?\d):([\d ]?\d)/
dow_name=
month_name = Sep
century =
day = 1
hour_24 = 05
hour_12 =
doy =
month =
minute = 39
ampm=
second = 02
nanosecond =
week_sun_0 =
dow_sun_0 =
dow_mon_1 =
week_mon_1 =
year_100=
year=
ce_year =
tz_offset =
tz_olson=
timezone=
epoch =
iso_week_year =
iso_week_year_100 =
Using timezone DateTime::TimeZone::UTC=HASH(0x9162350).
[2010/09/01 20:06:30] [WelfParser.pm:61] [INFO]
parser [BSD Syslog] experienced exception {
There is no use providing a month name (Sep) without providing a year.
at /homes/megahall/workspace/montage/src/Yahoo/Montage/WelfParser.pm line 55
}
[2010/09/01 20:06:30] [WelfParser.pm:65] [WARN]
processed time_str [Sep 1 05:39:02] into date_time [undef]
Re: DateTime::Format::Strptime bug report
It'd also be good to fix the bug where errors don't work if croak is
disabled. Makes it real hard to do good automated processing of
potentially bad input.
On Thu, Sep 02, 2010 at 10:55:16AM -0700, Matthew Hall wrote:
On Thu, Sep 02, 2010 at 01:24:03PM -0400, Metz, Bobby wrote:
You can add the current year to your string value prior to parsing.
Thanks. I'll adopt the DateTime based version in your second mail.
Of course you could also alter you syslog config to include the year,
right?
It's more complicated than that. This is part of some generalized code
to process a whole bunch of different weird timestamps coming in
through Syslog, and the BSD classic one was the one which was causing
me problems because the others were working. They were commented out in
the parser array to make the code easier to debug and explain in the
post. Some of the dates and times in the message header could be fixed,
but the ones inside the message themselves are stuck as they are.
Matthew.
-Original Message-
From: Matthew Hall [mailto:mh...@mhcomputing.net]
Sent: Wednesday, September 01, 2010 8:33 PM
To: datetime@perl.org
Subject: DateTime::Format::Strptime bug report
Hello all,
I am trying to parse BSD Syslog format time stamps, like this one:
Sep 1 05:39:02
Using the DateTime::Format::Strptime class, the call is failing with
the following result, when I use the format string '%b %d %H:%M:%S'.
There is no use providing a month name (Sep) without providing a year.
at /homes/megahall/workspace/montage/src/Yahoo/Montage/WelfParser.pm line
55
Searching for the error on the Internet even with the (Sep) removed
does not return any meaningful results.
I am wondering what I can do to fix this issue so I can get DateTime
working, or if there is a workaround of some sort. It does not seem
reasonable to croak or return undef time object because then there is
no way to set a valid year using a member function plus some external
year logic.
In addition, when trying to debug using the default on_error undef
setup, I discovered it is not possible to see this error message, and
that the $object-errstr() method mentioned in the documentation does
not seem to exist. Grepping the perl lib folder did not reveal it
either and I got an error trying to call it as well.
Further information below.
Thanks,
Matthew.
In the grep output; only a documentation passage is mentioned. This is
the passage from the documentation:
This is the default behavior. The module will return undef whenever it
gets upset. The error can be accessed using the $object-errstr method.
This is the ideal behaviour for interactive use where a user might
provide an illegal pattern or a date that doesn't match the pattern.
Here are my package versions.
DateTime-Format-Builder-0.7901_02
DateTime-Format-Epoch-0.10_01
DateTime-Format-ISO8601-0.0601_01
DateTime-Format-Strptime-1.0702_02
DateTime-Locale-0.42_01
DateTime-TimeZone-1.01_01
DateTime-0.5000_01
Here is a code snippet.
my @date_time_formats = (
# BSD: 'Mmm DD HH:MM:SS'
['BSD Syslog' , new DateTime::Format::Strptime(pattern =
'%b %d %H:%M:%S' , locale = 'en_US', time_zone = 'GMT', diagnostic
= $diagnostic, on_error = 'croak')],
);
sub welf_time {
my ($time_str) = @_;
$log-debug(process time_str [$time_str]);
my $date_time;
my $type;
my $parser;
for (my $i = 0; $i scalar(@date_time_formats); $i++) {
eval {
$type = $date_time_formats[$i][0];
$parser = $date_time_formats[$i][1];
$log-trace(call parser [$type]);
$date_time = $parser-parse_datetime($time_str);
$log-trace(return parser [$type] result [ .
display($date_time) . ] errstr [ . display($parser-errstr()) . ]);
};
if ($@) {
$log-info(parser [$type] experienced exception {...@}\n);
}
}
$log-log(!defined($date_time)? $WARN : $TRACE,
processed time_str [$time_str] into date_time [ .
display($date_time) . ]);
if (!defined($date_time)) {
$date_time = DateTime-now();
}
return $date_time-epoch();
}
Below is the log4perl output, along with diagnostic enabled on the
parser.
[2010/09/01 20:06:30] [WelfParser.pm:44] [DEBUG]
process time_str [Sep 1 05:39:02]
[2010/09/01 20:06:30] [WelfParser.pm:53] [TRACE]
call parser [BSD Syslog]
Entered = Sep 1 05:39:02
Parser= ($month_name, $day, $hour_24, $minute, $second) =
$time_string =~ /(\S+) ([\d ]?\d) ([\d ]?\d):([\d ]?\d):([\d ]?\d)/
dow_name=
month_name = Sep
century =
day = 1
hour_24 = 05
Re: DateTime::Format::Strptime bug report
On Thu, Sep 02, 2010 at 01:51:42PM -0500, Dave Rolsky wrote: Or you could do the simple version ... DateTime-now()-year(); Good call. Implemented. -dave Matthew.
Re: Article Titled Who's got the time? In Government Computer News
computed the value 1213129345. -- Jim Monty html body p***/p pThe information in this email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. When addressed to our clients any opinions or advice contained in this email are subject to the terms and conditions expressed in the governing KPMG client engagement letter./p p***/p /body /html -- Matthew O. Persico
Re: DateTime::Event again
On 5/16/07, Metz, Bobby [EMAIL PROTECTED] wrote: At a high level, recurring and single events don't have to have different properties IMO, depending on how you structure the series of event references. If you separate the event information from the scheduling, having an array, hash, whatever of scheduled events would simply hold references to the event object to access the event details. All event objects could have a recurring event property and the required extra parameters defining the recurrence. Any action on an object marked as a recurring event would kick off special routines to populate the extra event object references in the scheduling list or update those references if an event object is changed, deleted, or say converted to a standalone event. Just my 2 cents, Bobby Bobby brings up a point. If you go back a couple of threads where was a dissagreement about an event containing the multiple time information and putting multiple events (or, trivially, one event) into a list, you can come up with two maps. Let's look at the latter first DateTime::Event - who what where added, time inherited from DateTime DateTime::Schedule contains one or more events. If you try the former: DateTime::Event - who what where added, time inherited from DateTime, list of DateTime added as DateTime::Schedule if a recurrning event it doens't seem to fit. Heck, it doesn't even READ correctly to me. -Original Message- From: Dave Rolsky [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 16, 2007 2:04 PM To: datetime Subject: Re: DateTime::Event again On Wed, 16 May 2007, Simon Wistow wrote: On Wed, May 16, 2007 at 04:46:56PM +0100, Zefram said: A recurring event is not a single event. It is a structured group of events. You should have distinct classes for single event and recurrence. Most of the methods you list are applicable to one class or the other, not both. Hmm, I disagree. In every calendaring system I've come across a recurring event and a single event are represented as the same thing only with different properties. A recurring event is a single entity - it is one thing and should only be stored one time. I think you're mixing together the end-user view of an event and the program API view. Clearly, when one is programming a calendar system, recurring and single events would have to have some different properties. Using your description, a one-off event could be described as a structured group containing only one event. That's not a bad idea. A better distinction might be between a recurring event (every Tuesday at noon) and a specific instance of that recurring event (May 15 at noon). -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/ -- Matthew O. Persico
Re: recurring system
Once more.. I didn't see anything in the docs to prevent this 'cartesian product' effect. If I do this: my $dt_r = DateTime::Event::Recurrence-daily( days = [1, 3], hours = [10, 16], minutes = [0, 30]); I get the following events on Monday and Wednesday: 10:00 10:30 16:00 16:30 Is it possible to get just: 10:00 16:30 on Mon and Wed using only 1 D:E:R object? Thanks, Matthew
Re: recurring system
The documentation on D::E::Recurrence isn't helping me much. What am I
doing wrong here?
my $dt_start = DateTime-new( year = 2007,
month = 1, day = 15, hour = 11);
my $daily_at_10_30 = DateTime::Event::Recurrence-daily(hours = 10,
minutes = 30);
for(my $i = 0; $i 5; $i++)
{
print $daily_at_10_30-next($dt_start)-datetime . \n;
}
I'm expecting output like this:
2007-01-16T10:30:00
2007-01-17T10:30:00
2007-01-18T10:30:00
2007-01-19T10:30:00
2007-01-20T10:30:00
But getting this:
2007-01-16T10:30:00
2007-01-16T10:30:00
2007-01-16T10:30:00
2007-01-16T10:30:00
2007-01-16T10:30:00
Eventually what I will need to do is compare the -next recurrence with
the current (local) datetime and if the -next is less than that, get
next recurrence. But at this point, I can't even get simple recurrence
to occur.
Thanks,
-Matthew
Rick Measham wrote:
Matthew wrote:
Hey guys,
Does anyone have, already made, some type of recurring events
module? We have our in-house function that works with singular weekly
and singular monthly events but we'd like to branch into daily,
bi-daily, bi-weekly, bi-monthly, every X weeks, every X days, etc.
Like DateTime::Event::Recurrence?
my $bi_daily_at_10_30am_set = DateTime::Event::Recurrence-daily(
interval = 2,
hours = 10,
minutes = 30
);
http://search.cpan.org/dist/DateTime-Event-Recurrence/lib/DateTime/Event/Recurrence.pm
Cheers!
Rick Measham
Re: gmt-cst off by an hour
Thanks Zefram. To combat this issue in the future, should we be storing our customer's event information in our DB in GMT and doing all calculations using GMT? or store in their local TZ and calculate with local TZ? Our servers are all GMT if that makes any difference. Thanks, Matthew Zefram wrote: Matthew wrote: $dt-set_time_zone(US/Central); print +9weeks CST: . $dt-epoch . - . $dt-datetime . \n; This is wrong. US/Central doesn't refer to CST specifically. It refers to the US central timezone *including DST switches*. The date it's showing is in CDT, not CST. Try displaying $dt-time_zone_short_name as well, which will show what's going on. Many of these events were created before the DST switch. How should I be calculating these event dates so that 4PM 2 weeks ago still shows as 4PM tomorrow? Do the -add with the timezone already set. Thus: #!/usr/bin/perl use DateTime; my $dt = DateTime-from_epoch(epoch = 1168812000, time_zone = 'GMT'); print Date in GMT: . $dt-epoch . - . $dt-datetime . . $dt-time_zone_short_name . \n; $dt-set_time_zone(US/Central); print Date in cen: . $dt-epoch . - . $dt-datetime . . $dt-time_zone_short_name . \n; $dt-add(weeks = 9); print +9weeks cen: . $dt-epoch . - . $dt-datetime . . $dt-time_zone_short_name . \n; $dt-set_time_zone(GMT); print +9weeks GMT: . $dt-epoch . - . $dt-datetime . . $dt-time_zone_short_name . \n; yields: Date in GMT: 1168812000 - 2007-01-14T22:00:00 UTC Date in cen: 1168812000 - 2007-01-14T16:00:00 CST +9weeks cen: 1174251600 - 2007-03-18T16:00:00 CDT +9weeks GMT: 1174251600 - 2007-03-18T21:00:00 UTC -zefram
Re: gmt-cst off by an hour
Our customers, from all over the globe, can create events (both one-time and weekly recurring). The formula we are using to calculate the next instance of a recurring event is (in psuedo code): is current time less than event start? if so, return event start date/time. if not, add 1 week to event start. loop until current time is less than new event start and return new event start. The calculation for one-time events can be done in either local TZ or GMT. But when you throw in the adding of weeks to an original start date, should the orig start date be in local TZ or GMT? Thanks, Matthew Zefram wrote: Matthew wrote: Thanks Zefram. To combat this issue in the future, should we be storing our customer's event information in our DB in GMT and doing all calculations using GMT? or store in their local TZ and calculate with local TZ? That depends on what you need to do with the data. If you want to do date arithmetic that is affected by the customer's timezone then you definitely need to store which timezone that is. For any event information where it is only the absolute time that matters, I recommend storing in GMT. Perform calculations in GMT or local time depending on what type of calculation you intend to perform. Our servers are all GMT if that makes any difference. This is wise. -zefram
Re: ANNOUNCE: DateTime 0.60
Should I also be updating my /usr/share/zoneinfo/ and my MySQL tables with the new Olson db so that everything is current? -Matthew Dave Rolsky wrote: 0.60 2007-02-13 - This release is based on version 2007b of the Olson database. For the next release, I'm planning to integrate Zefram's work on handling SysV time zones and direct use of the binary Olson files. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
missing something..
am I missing something?
missing something..part 2
yea..missing the body..sheesh my $dt = DateTime-new( year = 2007, hour = 9, time_zone = Etc/GMT+5 ); The timezone 'Etc/GMT+5' in an invalid name. ?? I see all the Etc/GMT+X inside my /usr/share/zoneinfo/Etc/ so what's up? Are the Etc/GMT+X the proper generic time zones to use if your country/region isn't specified? Thanks, Matthew
Re: missing something..part 2
Thanks Zefram, Note the change of sign: for historical reasons the signs in the Etc/GMT+X names are the opposite of the actual offset. Wow. Yea, that caused me quite a headache. I didn't realize that. Spent forever trying to figure out why GMT+5 kept subtracting hours. but it doesn't include the Etc pseudo-zones. Ok. Well then I can't use em. I've got to be able to use zones that exist in Perl, PHP and MySQL. If your timezone isn't in the database, you should mail the database maintainers to get it added. Hehe. I'm the DBA. And I've updated everything to most recent stuff, but the boss man wants generic time zones in our list just in case a customer can't find his or doesn't realize his city is listed differently. Thanks, Matthew
recurring system
Hey guys, Does anyone have, already made, some type of recurring events module? We have our in-house function that works with singular weekly and singular monthly events but we'd like to branch into daily, bi-daily, bi-weekly, bi-monthly, every X weeks, every X days, etc. Our current logic for calculating the next event for a weekly event is thus: Take the original time stamp of the event. Compare that to current time. If eventTimeStamp is greater than current time, return that date/time. Otherwise, add 1 week to eventTimeStamp and compare again. Loop until eventTimeStamp is greater than current time. To me, this seems amazingly inefficient. If my weekly recurring original event start date was Aug 1, 2006, the perl would have to loop 26 times to find the next event (in this case, Jan 23). Can anyone offer a better solution to this? Thanks, Matthew
Re: recurring system
Well that was easy. Thanks Rick. I should have looked on cpan before emailing. -Matthew Rick Measham wrote: Matthew wrote: Hey guys, Does anyone have, already made, some type of recurring events module? We have our in-house function that works with singular weekly and singular monthly events but we'd like to branch into daily, bi-daily, bi-weekly, bi-monthly, every X weeks, every X days, etc. Like DateTime::Event::Recurrence? my $bi_daily_at_10_30am_set = DateTime::Event::Recurrence-daily( interval = 2, hours = 10, minutes = 30 ); http://search.cpan.org/dist/DateTime-Event-Recurrence/lib/DateTime/Event/Recurrence.pm Cheers! Rick Measham
Re: ANNOUNCE: DateTime::TimeZone 0.58
How can I ensure that all our linux servers are up to date with the 2007a Olson database? Or do I even need to make sure that they are? Does everyone out there have to update their zoneinfo to accommodate the new time changes? -Matthew Dave Rolsky wrote: 0.58 2007-01-08 - This release is based on version 2007a of the Olson database. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: simple calculation frustrations
Thanks for the link Philip. I downloaded and updated all my /usr/share/zoneinfo then imported them into MySQL using their mysql_tzinfo_to_sql tool. Is there a better way to store the time zone of our customers other than VARCHAR? I noticed that the utility above created an INT indexed table of tzID - tzName but those tables are in the mysql database and I'd rather not give users permission to that table. Plus that would complicate SQL queries further by adding in either A) another JOIN statement or B) an extra SELECT to convert the INT to a name. Any thoughts? Thanks, Matthew Garrett, Philip (MAN-Corporate) wrote: Matthew wrote: Ahh. And we have customers all over the world. Dang. See, all of this programming was done back shortly after we sprang forward so we didn't think about it. Any suggestions on how I should store a customers timezone in database? I think the best way is probably using the Olson time zone name. These are names like 'America/New_York' and 'Australia/Melbourne'. http://www.twinsun.com/tz/tz-link.htm Perl's DateTime module uses these time zones, as do MySQL = 4.1.3 and Oracle = 9i. Regards, Philip
Re: simple calculation frustrations
To clarify, this is all in reference to our event system. A customer can create an event for March 3, 2006 as a one time event or a weekly recurring event. We are storing '2006-03-03' in the database as the base date. In order to find the date of the next event, we take the base date from DB and add to that the increment value until the new base date is greater than today's date: $baseDate = from_db(); while($baseDate $today) $baseDate += increment -Matthew Zefram wrote: Dave Rolsky wrote: Pretty much all DBMS's (ok, not SQLite) have support for datetime as a data type. Worms. Can thereof. A datetime type is not a primary feature of a DBMS, so it's probably not had much attention paid to it. Until recently, MySQL's datetime type allowed dates such as 2006-04-31. Even if it's implemented correctly, it'll implement some arbitrarily selected date model that's not particularly likely to match your need. In this case, timezone behaviour is the issue, and not very many datetime types handle multiple timezones in the way desired. Using a DBMS's datetime type also loses you portability, of course. The advantage to this is that your datetime data is stored in a consistent way, so if you ever need to compare datetimes for some reason, you know that they'll compare sanely. I think what he wants to store isn't actually a date, as in a point in time. Looks like he wants to store a time of week, timezone-relative, along with a timezone spec. The incrementing loop he came in with is just answering the question when will that time of week next occur?. -zefram
Re: simple calculation frustrations
Ahh. And we have customers all over the world. Dang. See, all of this programming was done back shortly after we sprang forward so we didn't think about it. Any suggestions on how I should store a customers timezone in database? Thanks, Matthew Dave Rolsky wrote: On Thu, 2 Nov 2006, Matthew wrote: I tried to do so. The problem is that the date's are stored in the users local timezone and we only store the offset from GMT. (ex: -6 or 7) Well, there's your problem right there. You realy can't do this and expect it to work, as you're finding out. You need to store the user's timezone, not their current offset. If you know all your users are in the US you might be able to come up with some hacks to deal with DST, but otherwise you really need to let DT::TimeZone do this for you (or MySQL, or something). Is there some array or table I can use to convert '-6' to something DateTime:: can use? No, there's no way to go from offset to time zone. Again, if your users are all in the US, _and_ no one's in a weird zone (like Indiana, parts of Arizona, etc) then you can probably convert it back. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: DateTime performance
Then no lib isn't doing what you want.
Agree. But, that is the point. Outside of recompiling perl with new
paths or significantly altering DateTime to use far fewer
dependancies nothing can really be done.
test4
#!/usr/bin/perl
BEGIN { @INC = grep !/5\.8\.[0-5]/, @INC }
use DateTime;
[EMAIL PROTECTED] tmp]$ time perl test4
real0m5.780s
user0m5.524s
sys 0m0.188s
Matthew
Re: DateTime performance
Do your traces show it still searching all the removed paths? yes There's no way the above should be doing that, unless you're loading DateTime earlier, via sitecustomize.pl or $PERL5OPT? Neither of the items you have identified are used in any way during these tests. I would expect if either of those had been the issue then even test1 would be slow. Regards, Matthew
DateTime performance
noticeable delay for any command line scripts that might include DateTime. Matthew
DateTime::Format::ICal Usage/Compliance
I was looking to use this module in processing ICal files however I found issues in using it because it isn't clear to me how it was intended to be properly used given the ICal specification. Any way I look at using it it seems like duplicate effort will happen in my code and it if I'm going to safely use it for all RFC compliant cases. According to the RFC2445 specification all the following I believe are considered valid DTSTART lines that could be found in a RFC2445 compliant file. 1) DTSTART:19980118T23 2) DTSTART:19980118T073000Z 3) DTSTART;TZID=US-Eastern:19980119T02 And I believe if we pass DateTime::Format::ICal anything from the above past either what ever comes first : or ; for the above cases we are good. However I sort of find it a little odd that we would pass what the RFC calls parameters along with the value. But we also can have things like this. 4) DTSTART;VALUE=DATE:20051210 5) DTSTART;VALUE=DATE-TIME:19980118T073000Z 6) DTSTART;VALUE=DATE-TIME;TZID=US-Eastern:19980119T02 7) DTSTART;VALUE=DATE-TIME;TZID=US-Eastern;X-MYPARAM=hello: 19980119T02 8) DTSTART;VALUE=DATE-TIME;TZID=US-Eastern;X-MYPARAM=My Hello to you:19980119T02 As best I can tell DateTime::Format::ICal will not process any of the cases 4-8 if I just pass it everything after the first ;. If all DateTime::Format::ICal wants is the actual value and possibly the time zone parameter then it might make since to have the two values that the parser accepts parse_datetime(value) parse_datetime (value,timezone) if the intent is for parse_datetime to accept any of the above cases as value then it should support all of them. It just seems like extra work for me to decompose the whole string and then in one case have to put part of it back together if a timezone was included just so DateTime::Format::ICal can then again decompose it all over again. So to me I would rather see datetime either support two possible parameters or have it support all possible forms with the acceptance that it would never do anything with the X- properties but would ignore them if found and still process what it understands if it is all RFC compliant. Perhaps some hook for adding a custom module addon for processing X- hooks if needed would be nice but I'm not to worried about that. I haven't looked at all the other RFC properties that are dates to see if they are all identical to DTSTART so it may be possible that a bunch of other reasonable things are possible for other date based properties. I'm not actually a member of this list so if you have any questions for me please send me a e-mail directly. Regards Matthew
Re: Fwd: DateTime::Business
On 6/3/05, Rick Measham [EMAIL PROTECTED] wrote:
Matthew Persico wrote:
1) Add a convenience method called 'today' to DateTime, which is the
same as Date::Time-now-trunc(to=day)
Already there ..
$today = DateTime-today();
Hmm, don't know how I missed that one...
2) All business dates will have no time component. All decrements and
increments of business dates will be a number of days - I don't think
there is a concept of business weeks or months...
Absolutely disagree on this point. You have to have finer control than
days. If a project is going to take 100 man-hours and you have 7 people
working on it, you need to be able to do:
When I say business date in the US, I'm thinking in terms of dates on
which financial transactions are able to be executed or settled. Time
is irrelevant: for example, if the trade executes on a Friday, it
cannot settle on Sat or Sun because the are not business days. Hours
are irrelevant.
If I were writing an object to handle your examples below, I'd call it
DateTime::Calendar::Man (as in man-hours, man-days, man-weeks, etc,
with apologies to the other half of the human race...)
which would need a holiday calendar attached to it in some way (much
as my DateTime::Business would) to get the math right.
Between your comments and those of [EMAIL PROTECTED] prior to yours, I
am starting to think that the only right way to do this is to create
the calendar as a separate entity and feed it to DateTime instead of
trying to create Yet Another Sub Class of DateTime. The only thing I
have to account for in my world is setting time to 00:00
[snip]
Also, you cannnot ignore things like weeks and months. Especially
months. From a business POV, in Australia note the following behaviour
would be 'correct':
$this_year = DateTime::Calendar::Business::Australia-now-trunc( to =
year );
print $this_year-datetime;
# 2004-07-01T00:00:00
In Australia, the tax year start on July 1st and finishes on June 30th
and so truncating to year would have to return a July 1st date. In the
states I believe it's April 19th or some such.
In the US, April 15 is the date by which you have to file your tax
return for the previous year. The tax year is Jan 1 through Dec. 31
for all personal taxes. I don't know the effect on taxes for a
business with a fiscal year != physical year. Most file quarterly
anyway - the end of year may only affect when any refunds are actually
refunded to a business.
There's probably hundreds, if not thousands, of different ways of
defining business days and so I'd suggest implementing a simple way to
localize and cascade your data such as this:
package DateTime::Calendar::Business::Australia;
@ISA = qw/DateTime::Calendar::Business/;
$YEARSTART = { month = 7, day = 1 };
@BUSINESSHOURS = [
1 = [ {hour = 9}, {hour = 17} ],
2 = [ {hour = 9}, {hour = 17} ],
3 = [ {hour = 9}, {hour = 17} ],
4 = [ {hour = 9}, {hour = 17} ],
5 = [ {hour = 9}, {hour = 17, minute = 30} ],
6 = [ {hour = 9}, {hour = 12} ],
7 = [ ],
];
@PUBLICHOLIDAYS = [
{ month=1, day=26 }, #Australia Day
{ month=4, day=25 }, #ANZAC Day
{ month=12, day=25 }, #Christmas Day
{ DateTime::Event::Easter-new( day= -2) }, #Good Friday
{ DateTime::Event::Easter-new( day= 0) }, #Easter Sunday
];
package DateTime::Calendar::Business::MyCompany;
@ISA = qw/DateTime::Calendar::Business::Australia/;
@BUSINESSHOURS = [
1 = [ {hour = 9}, {hour = 17, minute = 30} ],
2 = [ {hour = 9}, {hour = 17, minute = 30} ],
3 = [ {hour = 9}, {hour = 17, minute = 30} ],
4 = [ {hour = 9}, {hour = 21} ],
5 = [ {hour = 9}, {hour = 21} ],
6 = [ {hour = 9}, {hour = 17} ],
7 = [ {hour =10}, {hour = 16} ],
];
__END__
Once you have all your definitions in place, then a
DateTime::Calendar::Business object should work just like a DateTime
object -- you should be able to truncate it, add to it, subtract from it
etc. Just have to remember that a day on your calendar is not the same
as a day on the gregorian calendar, your days are only 7 or 8 hours each
and you weeks are 5 or 6 days long.
Cheers!
Rick Measham
Aside from the use of hours, which I don't need,
--
Matthew O. Persico
Re: Fwd: DateTime::Business
Seems that your needs are merely an application of DateTime::Calendar::Business rather than the purpose of such a module. Yes, that's the conclusion I am coming to also. The module needs to be more generic than I originally envisioned if it is to be of general use. [snip] Aside from the use of hours, which I don't need, If you're going to write publicly available modules rather than solutions you keep in-house, you need to drop the concept of 'I don't need'. Actually, that was an incomplete fragment that was in the process of being deleted when I fat fingered the keyboard and sent the memo. Apologies. Anyway, I think I need to go back to the drawing board and re-think the proposal. But, hey, that's what trail balloons are for, yes? Thanks for your comments. -- Matthew O. Persico
Fwd: DateTime::Business
A search of the archives for the work 'business' yields the latest
thread as being from Aug 2004.
I have a module at work that wraps Date::Manip for regular dates. From
this, I derive a business date class. Being based on Date::Manip, it's
as slow as fill in your favorite explitive. Anyway, I have
determined that I don't need all of the date parsing routines of
Date::Manip, so I plan to rip out the guts of my module and replace it
with DateTime.
In order to do that, could just write a small routine to parse the few
input date formats I know I need to handle, slap in DateTime and be on
my merry way.
But I really feel like writing DateTime::Business. So, the following
is a proposal:
1) Add a convenience method called 'today' to DateTime, which is the
same as Date::Time-now-trunc(to=day)
2) All business dates will have no time component. All decrements and
increments of business dates will be a number of days - I don't think
there is a concept of business weeks or months...
3) The call to
use DateTime::Business
would be initialized with a function ref that is called each time a
DateTime::Business is incremented or decremented. The function would
determine that the resulting date is a business date. This hook will
put the functionality of determination in the end programmers hands.
In my case, the function would be memoized, would read in a database
table of weekends and holidays to a static hash on the first call to
it and just look at the hash to determine the validity of the business
date.
Someone else could use the code from further along in the thread
http://marc.theaimsgroup.com/?l=perl-datetimem=109299634113109w=2 to
set up the definitions of what a business day is (or is not).
4) DateTime::Business itself would provide add and subtract methods to
call this programmer-provided function and if after a incr/decrement,
the result is not a business date, keep adjusting in the current
direction until you get a business date. Examples: Wed June 1 - four
business days is Wed May 25 (skip Memorial day.) Wed May 25 + 4
business days is June 1.
The psuedo-code algorithm for DateTime::Business functions looks like
sub add_business_days {
my ($self, $days) = @_;
return $self-crement_business_days(days);
}
sub subtract_business_days {
my ($self, $days) = @_;
return $self-crement_business_days(days*-1);
}
sub crement_business_days {
my ($self, $days) = @_;
## This duration could be a static class member to save time and space
my $duration=DateTime::Duration-new( days= 1);
my $crement = $days/abs($days);
while ($days) {
$crement 0 ? $self-add_duration($duration) :
$self-subtract_duration($duration);
$days -= $crement;
## This is the part that skips non-business days by doing the
'crement w/o adjusting the $days_to_crement.
while (!$self-is_a_business_day()) {
$crement 0 ? $self-add_duration($duration) :
$self-subtract_duration($duration);
}
return $self;
}
Ok, I have provided the dartboard. Anyone care to thow some darts?
--
Matthew O. Persico
Subtraction Broken?
I'm not sure if I'm doing something really wrong or if things are broke but with this code: #!/usr/bin/perl use DateTime; $birth=DateTime-new(year=1968,month=6,day=28); print $birth-ymd.\n; $today=DateTime-today; print $today-ymd.\n; $age=$today-$birth; print $age-years.\n; I get this output: 1968-06-28 2003-08-17 0 That zero sure doesn't seem correct to me.
Re: Subtraction Broken?
Perhaps I'm just approaching this all wrong. I'm just looking for a simple way to compute some ones age today. 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 DateTime directly. But, what I request is something you all desire and hope to have working when someone has the time. I actually wouldn't mind taking a look to see if I could contribute but at this point if: 1968-06-28 2003-08-17 Years:0 Months:0 Days:2 Delta Months:0 Delta Days:12833 is viewed as correct in representing the duration between those two dates I feel I'm missing a little to much to grasp some of the basics to contribute. I really don't see what the years months days methods are all about and if the delta's are simply just supposed to all add up to the duration then I can make since of the Delta's but it seems like I should have some methods representing the deltas in other forms that would also include years. Do you have some other design specs for the DateTime::Duration module that might help me to understand the above output better. However if on the other hand some part of the output above although perhaps correct not exactly what is intended or just stubs for what is desired then if I new what was intended/desired I probably could take a look and see if the effort to produce what I desire from DateTime is worth it. If years really should produce 35 and simply isn't because that method is a stub I would be happy to see what I can produce.
DateTime used with Class::DBI
I'm not sure anyone is interested but I thought I would pass this along. I have started using Class::DBI and was hoping I could also use DateTime with it. Class::DBI has some hooks to allow for any type of Object to represent Time. However the one limitation it has is that you must be able to call a method with no parameters to produce the proper output for the database. So the only way I could use DateTime with it is if $datetime-somename() produces the correct format for the database I'm using. I have taken a look at the DateTime-Format-MySQL and it can produce the formats required however with out being able to get the format through a call as described above it will never work with Class::DBI. This isn't exactly a DateTime problem or a Class::DBI problem or a Database problem just an interaction issue that someone may or may not be interested in looking at. However as the two objects operate today I don't see them being compatible. If you are interested and have any additional questions feel free to ask. Thanks Matthew McGillis
Re: Parser Interface (Was Re: Picking up the ball)
On Monday, January 13, 2003, at 10:14 PM, Dave Rolsky wrote: I _don't_ want to discuss implementation of this. I want to talk about the API! Agreed; I'm making this argument specifically because I think the proposed API is clearer. Looking at the two alternatives, does the second really seem clearer? use DateTime; my $dt = DateTime-new( 'MySQL' = $mysql_dt ); print $dt-to_string( 'MySQL' ); use DateTime; use DateTime::Parse::MySQL; my $dt = DateTime-from_mysql_datetime( $mysql_dt ); print $dt-to_mysql_string(); Um, yeah, the second is _much_ clearer. Hmm... Really? To me, the first seems much clearer. If this framework grows in the future, won't we end up with dozens of parser/formatter modules all stuffing methods into the base class? And if someone wants to build a separate implementation of the DateTime interface, like the TAI64 code, how will they be able to integrate with those parsing/formatting modules, short of blindly making their code a subclass of the primary implementation? If there's a public consensus that most people prefer stuffing methods into the base package rather than having a gateway interface that dynamically dispatches calls to other classes, I'll drop the issue, but it seems to me like a significant mistake. And how is DateTime-new supposed to know about all the myriad parameters that would exist with your suggestion anyway? If it finds an unknown parameter, should it call DateTime::Parse-$param()? No, it would load a module named DateTime::Parse::$param, and then call a method on that class, eg DateTime::Parse::MySQL-parse_string(). And its less error prone as well! If I mis-type 'MySQL' as 'Mysql' then what is DateTime supposed to do? If you mis-enter the name of a module, it would die with a message along the lines of The $param format is unknown, and DateTime::Parse::$param can't be found in @INC; please check that you've written the format name correctly and that the associated module is installed on this host.; What if a specific parser needs _two_ params? Presumably it could accept an array-ref, or grab a list of arguments. Your first option is not on the table. Er, why not? The options on the table are: [...] or use DateTime; use DateTime::Parse::MySQL; my $dt = DateTime::Parse::MySQL-new_datetime( $mysql_dt ); print DateTime::Parse::MySQL-mysql_datetime( $dt ); That's a straw man -- AFAIK, nobody's suggesting this kind of API. Frankly, I think the first one is a lot easier to use and makes more sense. It's the decorator pattern without the dispatching overhead! I don't see the similarity to the decorator pattern. Decorators are a dynamic composition of objects, nestable such that you can stick one decorator in front of another, and each one is provided by a different class and so has its own namespace and inheritance tree. http://web.media.mit.edu/~tpminka/patterns/Decorator.html The proposed approach of having add-on modules stuff new methods into the core class's namespace lacks all of those qualities, and seems more reminiscent to me of the big ball of mud pattern then it does of some kind of optimized decorator. -Simon
Re: Which DOW is day #1?
On Sunday, January 12, 2003, at 10:48 AM, Rich Bowen wrote: On Sun, 12 Jan 2003, John Peacock wrote: We really have to go with ISO because that battle has already been fought and won(?) in the international community. Well, I was going to say the following: This is not about either ISO standard or backward compatibility with C, but about common usage. People think of Sunday as the first day, and so we should stick with that, so as not to confuse people. However, based on your comment, I'm not sure if that is the case. This is a classic localization problem, with the convention varying from one place and time to another. I've seen a number of indications that many, perhaps most, Europeans consider the week to start on Monday, and a quick Google search turned up more anecdotal support for this theory, ex: Many British calendars and diaries use Monday as the start of the week; but some still use Sunday. (http://www.merlyn.demon.co.uk/weekinfo.htm) Another source clarifies that starting on Sunday is in fact the original pattern, and that counting from Monday is a later development of European cultures, especially Protestant and German-speaking ones. (http://www.friesian.com/week.htm) Personally, I've always preferred calendar weeks that start on Monday, partly for the onomatopoeia (mONEday, TWOsday, 3ednesday, FOURsday, FrIVEsday, ...), and partly because it synched up with the school-day/work-day cycle. Synchronization to the work week is also useful in some kinds of business contexts -- if you're scheduling weekday shifts, it's more convenient for your work days to run from 1-5 than from 2-6 -- and I believe the ISO week-numbering work is based on existing practices in the manufacturing industry. Some desktop calendar software allows you to switch the display to Monday weeks, and many business-week planning calendars also start on Monday. In a sense, one would like to be able to treat this as a locale issue, so that a user could specify the convention used in their setting, in the same way that they can select the language used. (I'm in Germany, give me German day names and ISO weeks.) A simpler solution would be to support multiple interfaces: ($year, $week_num, $week_day) = $dt-greg_week(); ($year, $week_num, $week_day) = $dt-iso_week(); Callers could choose to request whichever number they wanted: - $dt-iso_week_day - 1..7 starting with Monday - $dt-iso_week_day_0 - 0..6 starting with Monday - $dt-greg_week_day - 1..7 starting with Sunday - $dt-greg_week_day_0- 0..6 starting with Sunday -Simon
Re: Discarding some fifteen functions/methods in favour of an enhanced strftime
On January 12, 2003, at 07:29 AM, Antonios Christofides wrote:
Get rid of the methods/functions returning year, month, day of week,
day of month, day of year, hour, minute, second, week of year, week of
month, whatever, and use an enhanced strftime [...]
This enhanced strftime is a very nice interface, in line with Perl
idiom, and should be easy to add to the code, but I think eliminating
the standalone methods is going to sharply reduce user acceptance of
the new module.
# Change the hour to 17
datetime_object - strptime('%Y-%m-%d %H:%M:%S',
datetime_object - strftime('%Y', '%m', '%d', '17', '%M',
%S'));
Ick. That's clearly not as nice as just saying $dt-hour(17).
-Simon
Re: Static objects with dynamic wrappers?
On Sunday, January 12, 2003, at 05:27 PM, Dave Rolsky wrote: On Sun, 12 Jan 2003, Matthew Simon Cavalletto wrote: Ick. That's clearly not as nice as just saying $dt-hour(17). Whether this method is an updater is an entirely different can of worms ;) If not, it'd presumably be easy to stick an updating decorator in front of it, using the same type of structure as in the dynamic wrapper for static objects class I proposed earlier. $dth-hour(17); # Really calls $$dth-clone( hour = 17 ) or equivalent # internal gymnastics, and then stores the resulting object. -Simon
DateTime Namespace (Was Re: Base object API/semantics)
On Sunday, January 12, 2003, at 05:55 PM, Dave Rolsky wrote: On Sun, 12 Jan 2003, David Wheeler wrote: The advantage is that the interface is exactly the same regardless of calendaring system, and we deal with the issues of allowing DateTime to return different calendar types right now, up front. [...] I really don't see the point of this. Other calendaring systems will have different APIs, that may or may not resemble the API that's most appropriate for the Gregorian calendar. For example, see Rich Bowen's Date::Discordian on CPAN. But in fact the Discordian calendar is a lot like the Gregorian calendar -- they have years, months (seasons), and days. Likewise the Hebrew calendar, and the Mayan. (The overlapping Tzolkin and Haab cycles in the Mayan calendar are reminiscent of the month and week cycles in the Gregorian calendar.) If the DateTime framework is sufficiently open and inviting, we have the opportunity to encourage convergence of modules supporting those calendars -- obviously, there'll be portions of the API that differ from calendar to calendar, but we can still share a common core interface of methods like from/to_epoch, from/to_julian, strftime, strptime, etc. -Simon
Re: DateTime Namespace
On Sunday, January 12, 2003, at 05:30 PM, Dave Rolsky wrote: [...] keeping in mind that calendar-specific modules will be DateTime::Calendar::X, not DateTime::X [...] I think the make Gregorian explicit line of reasoning actually supports moving the various calendars up to second-level namespaces, and filing the various Events and Algorithms at a level below those. Here's how the multiple-calendar namespace might look: # General-purpose gateway and temporal geometry DateTime -- Factory methods and class lookup DateTime::Calendar (POD only?) -- Common interface for calendars DateTime::Delta-- Difference between two points DateTime::Set -- A collection of points DateTime::Span -- A period between two points DateTime::SpanSet -- A collection of spans # Our core calendar DateTime::Gregorian-- Our primary, modern calendar DateTime::Gregorian::Language -- Internationalization DateTime::Gregorian::RichParser - Based on Date::Manip et al. DateTime::Timezone -- Interface to global offset data The main distribution would presumably only include these basic gateway/geometry modules and the Gregorian calendar, but it leaves room for a proliferation of interoperating modules: # Calendar algorithms, also expressable as infinite sets DateTime::Gregorian::LeapYear -- Was DateTime::Algorithm::Leapyear DateTime::Gregorian::Christmas -- Was DateTime::Event::Christmas DateTime::Gregorian::Easter-- Not written yet # Regional variations of the Gregorian calendar get namespaces DateTime::EasternOrthodox::Christmas DateTime::US::FourthofJuly -- Was DateTime::Event::FourthofJuly DateTime::Solar::Equinox -- Find equinox and solstice dates # Other calendars, with associated algorithms and events DateTime::Chinese -- Not written yet DateTime::Chinese::YearAnimal -- Was Date::Chinese DateTime::Discordian -- Was Date::Discordian DateTime::Discordian::SaintDays -- Not written yet DateTime::Hebrew -- Was Locale::Hebrew::Calendar DateTime::Hebrew::Passover -- Was DateTime::Algorithm::Passover DateTime::Mayan-- Was Date::Maya DateTime::Roman-- Not written yet # Specialized implementations might get their own namespaces DateTime::Epoch::Posix -- Just a blessed time() value DateTime::Epoch::HiRes -- Based on Time::HiRes DateTime::Epoch::TAI64 -- Based on Time::TAI64 DateTime::Epoch::TAI64N-- Based on Time::TAI64N # Other generic geometry or utility modules filed at top level DateTime::Handle::SelfUpdate-- Wrapper to allow $dt-hour(17) DateTime::Sequence -- Ordered set DateTime::SpanSet::SparseMatrix -- Some kind of efficient storage? Does this system seem confusing? If you didn't know what Gregorian meant, you might feel kind of lost, but otherwise I hope people will find it reasonably intuitive. Does the organization seem too broad, rather than deep? I'm trying to avoid asking people to put separately-distributed modules below the third level, to avoid 40-character monstrosities like DateTime::Calendar::Chinese::YearAnimal and DateTime-Calendar-Hebrew-Passover-1.0.tar.gz. Does it invite others to add their own modules? Pushing the main implementation down a level might seem like a meaningless detail, but my hope is that it helps to signal to other module authors that they're not going to be second-class citizens. -Simon
Re: Date::Julian
On Friday, April 12, 2002, at 07:40 PM, Frodo Baggins wrote: As far as I can understand, the problem is in the routines converting to end from day-month-year dates to JD. These routines are interesting in theyr own respect, so I written a module to handle them. If someone is interested, it can be found at http://shire.dnsalias.org/perl/Date-Julian-0.01.tar.gz Nice work; I like the automatic switch from Gregorian to Julian calendars. The module I've used for this purpose in the past is Time::JulianDay (on CPAN); it might be appropriate to add a reference to it in your SEE ALSO section. -Simon
