Re: datetime-namespace.pod
Added a missing head tag. -J -- On Mon, 9 Jun 2003, Joshua Hoblitt wrote: Here is the document I started that lists the DT namespaces. It's been just sitting on my disk for several weeks so I figure I might as well get it finished. It's pretty short on details - although I don't think much more needs to be added. Any comments? -J -- =pod =head1 DateTime::* Namespace Guidelines This document attempts to define the the various 2nd tier CDateTime namespaces and the appropriate functionality of modules residing there. =head2 Namespace Allocation CDateTime::* namespace is allocated by the C[EMAIL PROTECTED] mailing list. Do not create a new 2nd tier namespace without first seeking approval from the list. Unless specifically noted as Copen most 2nd tier namespaces are not available to 3rd party developers. =head2 Authors All DateTime authors are encourage to 1) consult the C[EMAIL PROTECTED] mailing list before uploading any module. 2) register their module's namespace with PAUSE. =head2 The Namespaces =over 4 =item * DateTime Obviously this is the root namespace. CDateTime.pm is the generic DateTime object implementing the Gregorian calendar. =item * DateTime::Calender Modules implementing calendars that can be converted to/from other CDateTime and other CDateTime::Calendar::* objects. Please see Cdatetime-calendar.pod for developer documentation. This is an Copen namespace. =item * DateTime::Duration This is a simple class for representing duration objects. These objects are used whenever you do date math with DateTime.pm. =item * DateTime::Event Modules implementing the occurrence of an event. This is an Copen namespace. =item * DateTime::Fiction This is somewhat of an unusual namespace. It is intended for modules implementing calendars from fictional works. This namespace is exempted from the requirement to be interpretable with CDateTime and CDateTime::*. This is an Copen namespace. =item * DateTime::Format Modules capable of parsing specific Date/Time formats and/or being able to format strings. This is an Copen namespace. =item * DateTime::Infinite Infinite past and future DateTime objects. =item * DateTime::Language The current implementation of DateTime language localization. CDateTime::Language is the base class and also provides a module loading facility. All modules under CDateTime::Language::* need to inherit from CDateTime::Language. =item * DateTime::LeapSecond Leap seconds table and utilities. =item * DateTime::Locale The new implementation of localization support for DateTime. This is as of yet unreleased. =item * DateTime::Set DateTime sets and set math. =item * DateTime::Span DateTime time-ranges. =item * DateTime::SpanSet Sets of DateTime spans. =item * DateTime::TimeZone Time zone objects and base class. =cut
Re: Converting to DT
On Mon, Jun 09, 2003 at 06:16:23PM -0500, Dave Rolsky wrote: On Mon, 9 Jun 2003, Joshua Hoblitt wrote: I just got back from Perl Whirl. Having spent most of the last week plugging DT as a replacement for many of the examples given in the talks, I think we need a converting to DT section in the FAQ or a separate document dedicated to this. For example (I saw this in many presentations ): use POSIX qw( strftime ); my $time = strftime( %Y-%m-%d %H:%M:%S, localtime() ); Of course, if this is _all_ you'll ever need, converting to DT is almost certainly a mistake. And the FAQ needs to make that clear. Perhaps in a When Inot to use DateTime section. I think including the key _facts_ from the recent heated debate (memory usage etc) would also be helpful. Tim.
Re: First things first
Dave Rolsky wrote:
On Tue, 10 Jun 2003, Rick Measham wrote:
Anyway, I've
applied it mostly, except that for era I used ACE and BCE, because
I'm really not comfortable favoring one religion over another inside
the core code.
That's cool .. I imagine that we'll change it in short-order to get it
from the Locale .. which makes me think of something that Locale might
need ..
Actually, I don't think so. Remember when I first looked at the ICU stuff
and posted about the problem for the Taiwanese era. Without knowing the
year 0 for a locale's epoch, we can't use the epoch name.
Yes, the existing era information isn't useful ATM. I've left it in because
it has future potential. I'll make this clear in the docs.
$locale = new DateTime::Locale::en_AU;
Actually, I'd expect something like
DateTime::Locale-new( locale = 'en_AU' );
Well, its currently DateTime::Locale-load('en_AU') - that's preferred over
new DateTime::Locale::en_AU; because it caches the returned locale
object. Either are valid though.
If the consensus is the constructor might take extra arguments in the
future, I can adjust it to accept both of the following:
DateTime::Locale-load('en_AU');
DateTime::Locale-load(locale = 'en_AU');
$locale-eras();
# returns ('BCE' and 'ACE')
$locale-eras('BC', 'AD');
# returns ('BC' and 'AD') and sets these in the $locale (but not
DT::Locale::en_AU)
I really think locales need to be immutable, or else users could get
really confused if they don't notice that set line.
Yes, there are loads of features that could be added, but I think it should
be KISS if possible.
You're always welcome to provide a custom subclass like 'en_AU_RM' ;)
Yes, that's why the language_territory_variant locales exist, and I'd bung
them in a different @INC path to make it absolutely clear that they are
custom locales.
Cheers,
Rich
--
Richard Evans
[EMAIL PROTECTED]
Re: Is there any need to support ISO 639-2 language codes in DT::Locale?
On Monday 09 Jun 2003 2:52 am, Eugene van der Pijll wrote: There are many languages that have only a ISO 639-2 code. At the moment, two of them are supported in DateTime (sid = Sidama, and tig = Tigre), and one language without any ISO code (x-drs = sil-drs = Gedeo). All of these are Ethiopian languages, I think. These languages are not included in your DT::Locale package, but they should probably be added before DT::Loc replaces DT::Lang in the DT core. Just found the Yeha Locales for East Africa project: http://yeha.sourceforge.net/ I'm just waiting to get clarification on licensing, and then I'll try to get at least some of these added - looks like I might have to do it by hand though :( Cheers, Rich -- Richard Evans [EMAIL PROTECTED]
Re: 3 letter timezones (was month name to number)
Any progress on this?
-ben
On Wed, Apr 30, 2003 at 12:30:01PM +1000, Rick Measham wrote:
On Tue, 29 Apr 2003, Joshua Hoblitt wrote:
I was thinking of something similar to the 'constant' syntax that
quietly creates namespaces.
use DateTime::TimeZone::Alias HST = 'US/Hawaii';
.
.
my $dt = DateTime-new( year = 2003, time_zone = 'HST' );
That seems like the most tidy way of doing things. Of course I won't
have time to work on this for several days so I may not get a vote. :)
On 30/4/03 11:42 AM, Dave Rolsky at [EMAIL PROTECTED] spake thus:
The problem is that parsers need more than this, since they can't just set
a static list of aliases in advance. They have to be able to have EST be
interpreted in multiple ways.
I'm looking at setting a range of 'standard' aliases and allowing options:
use DateTime::TimeZone::Alias EST = 'Australia/Melbourne';
my $dt = DateTime-now( time_zone = 'EST' );
print $dt-offset;
# Returns 36000
use DateTime::TimeZone::Alias EST = 'America/New_York';
my $dt = DateTime-now( time_zone = 'EST' );
print $dt-offset;
# Returns -14400 even though EST is standard time and NY is in Daylight time
because EST is mapped to 'America/New_York'.
use DateTime::TimeZone::Alias;
my $dt = DateTime-now( time_zone = 'EST' );
print $dt-offset;
# Returns -14400 (assumes most people will be thinking about USA).
Apart from the standard zones I'd include other ones like using 'AEST/V' and
'AEST/M' for Australian Eastern Standard/Summer time in Victoria.
'AEST' would default to Sydney (as would 'AEST/NSW' and 'AEST/S') simply
because most people would be expecting Sydney (most of the world seem to
think it's our capital city!)
use DateTime::TimeZone::Alias 'I have a lovely bunch of coconuts' =
'America/Hawaii';
my $dt = DateTime-now( time_zone = 'I have a lovely bunch of coconuts' );
# Obviously the result is Hawaii, I just added this to demonstrate the
ability to use anything as an alias.
I'd also include the A-Z zones (And might even include Adelaide and other
1/2 hour zones as 'X.5'!)
Hmmm .. as I type this I wonder if we should also allow aliasing to custom
zones:
my %NO_DST = (
dst_start_month = 0,
dst_start_day = 0,
dst_start_hour = 0,
dst_end_month = 0,
dst_end_day = 0,
dst_end_hour= 0,
offset = 36000,
dst_offset = 36000,
);
use DateTime::TimeZone::Alias EST = \%NO_DST;
my $dt = DateTime-now( time_zone = 'EST' );
print $dt-offset;
# Returns 36000
For setting things 'permanently' maybe we should read
$ENV{DATETIME_TZ_ALIAS} and ~/.DATETIME_TZ_ALIAS
Developers hooking onto aliases really should either:
1. Provide their own aliases
2. Provide their own data file
3. Not mind if things get screwy
4. Get run over by a large bus.
Cheers!
Rick
Re: Converting to DT
FAQ answers should answer more questions then they generate, but two obvious questions leap out of that code... 1. Why is set_time_zone() needed for this DateTime example? Good point - that should be added to the description. 2. Why use DateTime::Format::*MySQL* when the code may have nothing to do with MySQL, it just happens to use the same, very common, format? It is a mySQL time format. I do think there should be a DateTime::Format::Common with a parse_datetime() that can handle common _unambiguous_ numeric formats. A single regex could handle all formats that follow the ISO 8601 general left-to-right decreasing resolution style, with assorted optional punctuation, plus optional appended TZ. Months ago I looked stealing the Date::Manip parser and decided to save that for a very rainy day. :) I did start to implement all of ISO8601 with DT::F::Builder but I haven't worked on it since April. Instead of a single large regex I'm going the many small regexs route. The problem is the ISO8601 defines a lot of unusual date formats - although releasing something with only partial compliance shouldn't be too hard. I'll try to get something into the workable state and release it later this week. -J --
Re: Converting to DT
Ah. I am working on that. I decided to use Parse::RecDescent as a base. I have a working ISO8601 (is http://www.w3.org/TR/NOTE-datetime complete?) and I have it parsing simple dates and times... Next on my list is making it understand all of the weird and wonderful things that Date::Manip can do (and more) and making sure that it is possible to localize it. The reasons I decided to go with Parse::RecDescent rather than the regexps that Date::Manip uses: 1) Expressing it as a grammar is more clear 2) Parse::RecDescent allows reconfiguration of the rules, so that if we need to change stuff when localizing that would work Some mix of the above also apply to DT::F::Builder too. However, I have no idea how fast this is and how much memory it consumes. I will try to release what I have tonight (when I hope to have it in a more usable state). -ben On Tue, Jun 10, 2003 at 08:39:50AM -1000, Joshua Hoblitt wrote: FAQ answers should answer more questions then they generate, but two obvious questions leap out of that code... 1. Why is set_time_zone() needed for this DateTime example? Good point - that should be added to the description. 2. Why use DateTime::Format::*MySQL* when the code may have nothing to do with MySQL, it just happens to use the same, very common, format? It is a mySQL time format. I do think there should be a DateTime::Format::Common with a parse_datetime() that can handle common _unambiguous_ numeric formats. A single regex could handle all formats that follow the ISO 8601 general left-to-right decreasing resolution style, with assorted optional punctuation, plus optional appended TZ. Months ago I looked stealing the Date::Manip parser and decided to save that for a very rainy day. :) I did start to implement all of ISO8601 with DT::F::Builder but I haven't worked on it since April. Instead of a single large regex I'm going the many small regexs route. The problem is the ISO8601 defines a lot of unusual date formats - although releasing something with only partial compliance shouldn't be too hard. I'll try to get something into the workable state and release it later this week. -J --
Re: Converting to DT
I am working on that. I decided to use Parse::RecDescent as a base. I have a working ISO8601 (is http://www.w3.org/TR/NOTE-datetime complete?) and I have it parsing simple dates and times... That document isn't anywhere close to what is defined by ISO 8601:2000. http://www.pvv.ntnu.no/~nsaa/8601v2000.pdf Parse::RecDescent sounds like an interesting idea - I'm eager to see what you've got. -J --
Re: First things first
On Mon, 9 Jun 2003, Dave Rolsky wrote:
Attached is DateTime.diff. This file contains extensions to DateTime
to allow it to match the outputs of the ICU project.
Strftime has also been patched to allow one to use methods as
strftime tokens: '%H' returns the same as '%{hour}'
Once Dave has approved this patch, or at least the names of the new
methods, I can provide Richard Evans with the convertor file for the
ICU locales and I can prepare the new strptime, removing the
customised strftime (and with object based croak behavior).
Somehow I either didn't notice this or forgot about it. Anyway, I've
applied it mostly, except that for era I used ACE and BCE, because I'm
really not comfortable favoring one religion over another inside the core
code.
Ok, I'm also _really_ confused about week_month(). What the heck is this
supposed to return? For July 5, 2001 it's returning 2, which seems wrong
to me, since July 5 is clearly part of the first week of July.
The comment mentions ISO but I find no reference to such a thing in
ISO8601.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: Converting to DT
I played with P::RecDescent for Mason, and it is slow and a memory hog. That's no dis to Damian, cause it's a great tool, but in most cases a custom regex-based parser is way faster. I talked to Damian about it at Perl Whirl and he said he's got plans for a major rewrite. Although we all know how busy he is. -J --
Re: Converting to DT
On Tue, 10 Jun 2003, Joshua Hoblitt wrote: I played with P::RecDescent for Mason, and it is slow and a memory hog. That's no dis to Damian, cause it's a great tool, but in most cases a custom regex-based parser is way faster. I talked to Damian about it at Perl Whirl and he said he's got plans for a major rewrite. Although we all know how busy he is. He's had those plans for over a year, I think ;) -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: First things first
At 3:53 PM -0500 10/6/03, Dave Rolsky wrote:
Ok, I'm also _really_ confused about week_month(). What the heck is this
supposed to return? For July 5, 2001 it's returning 2, which seems wrong
to me, since July 5 is clearly part of the first week of July.
The comment mentions ISO but I find no reference to such a thing in
ISO8601.
This one does something the old one doesn't .. it works!
# ISO says that the first week of a year is the first week containing a
# Thursday. Extending that says that the first day of the month is the
# first week containing a Thursday. ICU agrees.
sub week_month {
my $self = shift;
# Faster than cloning just to get the dow
my $first_wday_of_month = (8-($self-day - $self-dow) % 7) % 7;
$first_wday_of_month = 7 unless $first_wday_of_month;
# I hate to admit that I have no idea how I got this to work,
# but it does! (and I didn't copy it from a book either!)
my $wom = int(($self-day + $first_wday_of_month - 2) / 7);
return ($first_wday_of_month = 4) ? $wom+1 : $wom;
}
--
There are 10 kinds of people:
those that understand binary, and those that don't.
The day Microsoft makes something that doesn't suck
is the day they start selling vacuum cleaners
Write a wise proverb and your name will live forever.
-- Anonymous
RFC: Adding custom locales to DateTime::Locale
Hi everyone
It's clear that some folks are going to need custom locales whatever the
coverage of the core DT::Locale modules. It's also pretty clear that
DT::Locale isn't very friendly when you want to such locales:
Currently you have to add an entry into the DateTime::Locale::_locale method
array, which gets clobbered every time a new release of DT::Locale happens.
Not nice.
What I propose is this:
1) Add a register_locale method to DateTime::Locale:
DateTime::Locale-register_locale(de = 'deu', 'ger', 'German', 'Deutsch');
Arguments are: locale id, ISO 639-2(T) equivalent, ISO 639-2(B) equivalent,
English locale name, Native utf8 locale name. These will all be required
for the next DT::Locale release anyway.
Once registered, the locale can be load() ed and treated like any of the
core Locale modules.
2) Somewhere at the top of DateTime::Locale, add:
eval
{
require DateTime::Locale::LocalInstall;
DateTime::Locale::LocalInstall-import;
};
DateTime::Locale::LocalInstall is guaranteed never to be supplied with
DateTime::Locale - it's solely designed for users to register their custom
locales, and will look something like:
package DateTime::Locale::LocalInstall;
use strict;
use DateTime::Locale;
sub import
{
# Register as many custom locales as you like here
DateTime::Locale-register_locale(en_GB_RIDAS1 = 'eng_GB_RIDAS1',
'eng_GB_RIDAS1',
'eng_GB_RIDAS1',
'Ridas custom locale1',
'Ridas custom locale1');
}
1;
Obviously I'd provide the code template in the DT::Locale docs somewhere.
So this is how it would work - you write custom locales, shove them in one
of the @INC paths (preferably different to the DT::Locale install path) and
add the LocalInstall module which is used to register your locales.
Reasons why I like it:
1) New DT::Locale releases will not effect installed custom locales - no
hacking DateTime::Locale.pm to add new entries.
2) Easy to implement - just done it ;-
Reasons why its evil:
That's for others to comment on!
Does this make sense? Any suggestions?
--
Richard Evans
[EMAIL PROTECTED]
Re: Converting to DT
That's too bad. Anway, I am going to keep playing with this for a bit until I get all of the functionality I want, then I can convert it to a re-based thing. -ben On Tue, Jun 10, 2003 at 03:30:05PM -0500, Dave Rolsky wrote: On Tue, 10 Jun 2003, Ben Bennett wrote: However, I have no idea how fast this is and how much memory it consumes. I will try to release what I have tonight (when I hope to have it in a more usable state). I played with P::RecDescent for Mason, and it is slow and a memory hog. That's no dis to Damian, cause it's a great tool, but in most cases a custom regex-based parser is way faster. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: RFC: Adding custom locales to DateTime::Locale
So this is how it would work - you write custom locales, shove them in one of the @INC paths (preferably different to the DT::Locale install path) and add the LocalInstall module which is used to register your locales. It would be nice if modules could reside in arbitrary namespaces. For example Foo::TimeApp::BarLocale could be registered as a custom locale. Of course some mechinism for modules to register themselfs, like when installed from CPAN, would be nice as well. -J --
Re: RFC: Adding custom locales to DateTime::Locale
On Wed, 11 Jun 2003, Rick Measham wrote: I'd really like to not depend on Locale.pm other than as a loader for normal, included Locale methods. Can we just have an API that any module could potentially use? I think we need this, but we may also need a way to hook locales into DateTime::Locale. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: RFC: Adding custom locales to DateTime::Locale
Can we just have an API that any module could potentially use? Now thats just entirely too rational. Thank you for articulating my frustration. $locale = new My::Locale; $dt = DateTime-new(%date, locale = $locale); I always assumed that we'd be getting this as it currently works for DT::Language objects. -J --
Re: RFC: Adding custom locales to DateTime::Locale
Can we just have an API that any module could potentially use? I think we need this, but we may also need a way to hook locales into DateTime::Locale. And I think the next question is: Should this be at run-time or should there be a persistent registry? -J --
DateTime::Duration is_positive bug?
In DateTime::Duration:
sub new():
...
unless ( grep { $self-{$_} } qw( months days ...
{
$self-{sign} = 0;
}
and then:
sub is_positive { $_[0]-{sign} == 1 ? 1 : 0 }
which makes a zero-duration be not positive,
because sign is zero.
- Flavio S. Glock
Re: DateTime::Duration is_positive bug?
On Wed, 11 Jun 2003 [EMAIL PROTECTED] wrote:
In DateTime::Duration:
sub new():
...
unless ( grep { $self-{$_} } qw( months days ...
{
$self-{sign} = 0;
}
and then:
sub is_positive { $_[0]-{sign} == 1 ? 1 : 0 }
which makes a zero-duration be not positive,
because sign is zero.
That was an intentional change. Zero isn't positive, is it?
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
milli/micro seconds
I've started on milliseconds and microseconds support (DT::Duration to start with). I hope nobody else has already done this. -J --
