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
>
>