Re: new DateTime::Format module
Thanks again for the feedback. I appreciate the ideas very much and
look forward to working with everyone on this a bit.
Here are the issues that need addressed as I see them, I'd love to
hear your thoughts as well:
As far as locale data goes, it'd seem to make the most sense to put
all the common CLDR in DateTime::Locale, its central, it standard.
There still needs to be a recommended Localization procedure for
DateTime::Format based modules because
a) its being done inconsistently
b) not all things will be able to use CLDR only.
An example of those are DateTime::Format::Human which uses an internal
hash of the data with ISO code's as keys (except the funny ones are
not prefixed w/ i-) , DateTime::Format::Baby which also uses a hash
but uses the long-english version of the language as the key (IE
'English')
What I think would be ideal is:
- DateTime::Locale has all date time related info scraped from CLDR
- if a module needs localization it uses everything you can from
there
- if the available data is not fully sufficient for the goal of
the module then a ::Locale subclass that has a method to get the data
and/or logic from Locale::en, Locale::fr, etc
What I am attempting is a single format only. One that requires no
logic from the programmer to determine the language to use or the
details of the format.
The way my module does this is it determines the locale based on the
DT based objects involved and/or arguments. Tries to load
it's ::Locale::XX and use the data/logic from there for that and
future requests (from specific to generic E.g en_us, then en).
In this case CLDR would be very reusable there with the names
involved, probably 'and' and the oxford comma. There is still no
facility for saying 'no time difference' and the logic is still forced
to be english centric in the single/plural senses (what about dual
tenses?) and in the structure of the phrase (hence the locale method
to do the logic anyway they need to)
That is why CLDR is defintley a good idea but won't be a 'Universal
Catchall' since logic is involved and hence the ::Locale subclass
idea. The logic for determining the locale that should be used can
easily be (and was originally but I decided to wait and see how it'd
fit into the DateTime project's Locale setup first)
As far as DateTime::Format::Duration goes it would seem to me to be
exactly what it is: a strftime type method for durations. It processes
any given format. Period,its perfect, don't mess with that.
Besides it'd be difficult and not really fit anyway to make it
generate those formats for you because there are all sorts you might
want:
1 day, 3 hours, and 37 seconds (what mine does)
4 score and 7 years
hour and a half
little over a year
few months
month of sundays
pretty soon
etc
plus locale wise you have to consider:
singular, dual, plural, maybe even zeroth
past present and future tenses
perfect imperfect aspects
etc etc
In summary, it would be awesome to fetch from DateTime::Locale what
you can but also have a consistent way to encapsulate locale info/
logic very specific to the format a given module is going for.
All of that said, I'm more than happy to work with Dave or Rick or
anyone on any modules to get it so it all fits together nicely, let me
know!
Perhaps DateTime::Format::Duration::TYPE should be what work with a
specific format type and any locale data/logic not in DateTime::Locale
can be in DateTime::Format::Duration::TYPE::Locale[::XX] ?
In the meantime, we work at getting DateTIme::Locale to hold all the
datetime related data from CLDR ?
What do you think?
On Jul 28, 2008, at 8:12 PM, Rick Measham wrote:
Dave Rolsky wrote:
This all seems like it could go into DT::F::Duration though, just
with different strftime-type specifiers (or CLDR, or whatever).
Absolutely it could and should. %c and %x and %X would be the
obvious first candidates along with the alternate %{...} format for
other CLDR formats.
Dan, please consider working at extending DateTime::Locale to
include the duration formats and then working at helping me to
extend DateTime::Format::Duration to make use of that data.
Alternately, once CLDR duration locales are imported into
DateTime::Locale, write a module named something like
DateTime::Format::Duration::Locale that makes use of the data.
The normalisation functions in DateTime::Format::Duration give it
its real power so I would suggest you wrap the _as_deltas methods in
whatever you decide to do.
Cheers!
Rick Measham
--
Message protected for iSite by MailGuard: e-mail anti-virus, anti-
spam and content filtering.
http://www.mailguard.com.au
Re: new DateTime::Format module
On Mon, 28 Jul 2008, Dan Muey wrote: Thanks for the feedback, I've replied inline below. Please let me know if you have any other questions or suggestions. On Jul 27, 2008, at 4:12 PM, Dave Rolsky wrote: On Sun, 27 Jul 2008, Flavio S. Glock wrote: re: http://search.cpan.org/dist/DateTime-Format-Span/ This module seems to handle durations, instead of spans. A duration is span of time no? This module uses 'span' to mean 'the duration of time spanning 2 points in time' (plus ::Duration was taken) Right, the confusion is that there is a DateTime::Span class, and I'd expect DateTime::Format::Span to take an object of that class and format it. However, your module only operates on durations. Even more confusingly, it offers a format_duration method which only accepts a single duration, which is _not_ a span. This really is not a good name for your module, because of this reason. The real difference is that it is simply not how a human would say it. For example from ::Duration's POD regarding its output: 3 years, 5 months, 1 days, 6 hours, 15 minutes, 45 seconds For English: a) '1 days' should be '1 day' b) 45 seconds should be 'and 45 seconds' (keeping the oxford comma) In my original draft I sent to Dave, when it was not under DateTime::Format like it should have been, I had this in an FAQ, I should probably add it back, Why didn't you just use 'DateTime::Format::Duration' Essencially it is a strftime for a Duration. This is not flexible enough for the intent of this module. DateTime::Format::Duration is not a bad module its just for a different purpose It was not localizable You either got '2 days' or '1 days' which a) forces it to be in English and b) doesn't even make sense in English. You could get around that by adding logic each time you wanted to call it but that is just messy. Had to keep an item even if it was zero If 'days' was in there you got '0 days', we only want items with a value to show. That'd also require a lot of logic each time you wanted to call which is again messy. This all seems like it could go into DT::F::Duration though, just with different strftime-type specifiers (or CLDR, or whatever). As far as localization, I'd prefer to see locale-specific data as part of the DateTime::Locale module itself. In fact, CLDR 1.6 does include a bunch of stuff for formatting spans in a locale-specific way. I haven't integrated that into DT::Locale yet, because I want to figure out how to actually use it. That'd be great! The way I did this for now was that ::Span::Locale determined what locale to use based on the datetime object's and/or args then loads Span::Locale::XX if possible and uses the data it defines. Some of the information you define in the locale modules does exist in CLDR, notably singular versions of things like day, month, etc. CLDR also includes formats for doing things like formatting a span based on the greatest unit of differnece between two dates. It's rather complicated, so I haven't implemented it yet. Basically, it lets you format something intelligently so you get Jan 10-12 vs Jan 10 - Feb 10. -dave /*== VegGuide.Org Your guide to all that's veg ==*/
Re: new DateTime::Format module
Dave Rolsky wrote:
This all seems like it could go into DT::F::Duration though, just with
different strftime-type specifiers (or CLDR, or whatever).
Absolutely it could and should. %c and %x and %X would be the obvious
first candidates along with the alternate %{...} format for other CLDR
formats.
Dan, please consider working at extending DateTime::Locale to include
the duration formats and then working at helping me to extend
DateTime::Format::Duration to make use of that data.
Alternately, once CLDR duration locales are imported into
DateTime::Locale, write a module named something like
DateTime::Format::Duration::Locale that makes use of the data.
The normalisation functions in DateTime::Format::Duration give it its
real power so I would suggest you wrap the _as_deltas methods in
whatever you decide to do.
Cheers!
Rick Measham
--
Message protected for iSite by MailGuard: e-mail anti-virus, anti-spam and
content filtering.
http://www.mailguard.com.au
new DateTime::Format module
re: http://search.cpan.org/dist/DateTime-Format-Span/ This module seems to handle durations, instead of spans. How about naming it DateTime::Format::Duration instead? - Flavio S. Glock
Re: new DateTime::Format module
On Sun, 27 Jul 2008, Flavio S. Glock wrote: re: http://search.cpan.org/dist/DateTime-Format-Span/ This module seems to handle durations, instead of spans. How about naming it DateTime::Format::Duration instead? Well, such a module already exists! Daniel, Flavio raises a good point, though. What is the point of your module, and how is it different from DT::F::Duration? As far as localization, I'd prefer to see locale-specific data as part of the DateTime::Locale module itself. In fact, CLDR 1.6 does include a bunch of stuff for formatting spans in a locale-specific way. I haven't integrated that into DT::Locale yet, because I want to figure out how to actually use it. -dave /*== VegGuide.Org Your guide to all that's veg ==*/
New DateTime::Format::* module
I have written a new module that simply parses dates in several different formats. The reason I have written this on is that every existing parser from this project that I've tried has fallen short in one area or another, particularly in parsing our most commonly used format, MM/dd/. * DateTime::Format::DateManip: Try this from any location that recognizes Daylight Saving Time: my $dt = DateTime::Format::DateManip-parse_datetime( 1/1/2006 ); $dt-truncate( to = 'day' ); print( $dt ); 2005-12-31T00:00:00 This is obviously incorrect, but there is not way that I know of to fix it, because Date::Manip takes the local time zone and DST status into account, even though it's not specified. * DateTime::Format::DateParse. Will not parse dates prior to 12/14/1901. In some systems (Informix, particularly), the zero or epoch date is 12/31/1899. Therefore this one will not work either. * None of the other parsers I've found will parse MM/DD/ format (along with the many other formats). Right now, I've called the module DateTime::Format::SimpleParser. If anyone has a suggestion for a better name, I'm all ears. Also, what is the best way for me to get this module to the community for use (I have no idea how to upload it to CPAN, so if that's the best way, could someone point me in the right direction?). Thanks, Peter Conrey Today's mighty oak is just yesterday's nut that held its ground
Re: New DateTime::Format::* module
Peter Conrey wrote:
I have written a new module that simply parses dates in several different
formats. The reason I have written this on is that every existing parser from
this project that I've tried has fallen short in one area or another,
particularly in parsing our most commonly used format, MM/dd/.
I've some glue that I've called DateTime::Format::TimeParseDate that
glues Time::ParseDate to DateTime. I love it because it normally
does-what-you-mean to the point of understanding Yesterday at 2pm or
Midnight next Wednesday.
I haven't released it because it isn't documented at all and I've not
written any tests. I've attached it in case it helps.
Cheers!
Rick Measham
package DateTime::Format::TimeParseDate;
use strict;
use warnings;
use DateTime;
use Time::ParseDate qw//;
use Params::Validate qw/validate BOOLEAN/;
sub parse_datetime {
my $class = shift;
my $date = shift;
my %inarg = @_;
my %arg;
foreach ( keys %inarg ) {
$arg{ uc( $_ ) } = $inarg{ $_ };
}
my $epoch = Time::ParseDate::parsedate( $date, %arg );
my $dt = DateTime-from_epoch(epoch = $epoch);
if ($arg{TZ}) {
$dt-set_time_zone( $arg{TZ} );
}
return $dt;
}
#print STDERR Loaded DateTime::Format::TimeParseDate 0.0001_01;
1;
