Hi,
I just subscribed to this list after seeing the article in use.perl.org.
I apologize if this topic has been discussed before...
I got the CVS version of DateTime.pm, and I noticed there wasn't a
single Asian DateTime::Language module. So I thought I might do a
> I suspect that same goes for some Asian languages.
by the way, I think that the languages we have are
using "latin1".
Maybe we should make it UTF8.
- Flavio S. Glock
On Mon, 31 Mar 2003 [EMAIL PROTECTED] wrote:
> > I suspect that same goes for some Asian languages.
>
> by the way, I think that the languages we have are using "latin1".
> Maybe we should make it UTF8.
Yes, we should, since that's the future of Perl. But then we'd have to
provide a "bytes" vers
On Mon, 31 Mar 2003, Daisuke Maki wrote:
> I got the CVS version of DateTime.pm, and I noticed there wasn't a
> single Asian DateTime::Language module. So I thought I might do a quick
> hack and get you guys the Japanese version...
It's certainly welcome.
> Then I
ever be one or two weeks away from Western Easter. Then someone with an
Orthodox background popped up and I had to rethink everything! Its one of
the great things about community development!
> Then I noticed that DateTime::Language only has attributes for month
> names, day names, and am/pm
On Tue, 1 Apr 2003, Rick Measham wrote:
> sub format_datetime {
> $dt = shift;
> return sprintf("%s%s%s%s%s%s %s%s%s%s%s%s",
> japanese_number($dt->year),
> 'japanese_for_year',
> japanese_number($dt->month),
> 'japanese_for_month',
> japanese_number
So, now that I've thought about this a bit more -- my question turns to
this: If DateTime::Format::Japanese is where my original idea is
supposed to go (which I agree, now that I know of its existance),
wouldn't that effectively mean that that's where all of the
Dat
ively mean that that's where all of the
> DateTime::Language::* functionality also should go? Aren't the
> functionalitites in those modules also formatting -- why are month names
> and day names any different from other locale/language specific notation
> like what I mentioned i
On Mon, 31 Mar 2003, Daisuke Maki wrote:
>> I think I'd feel better if all of that locale/language specific stuff
>> was in one place? Maybe strftime() should be absorbed there ...?
On 1/4/03 12:37 pm, Dave Rolsky at [EMAIL PROTECTED] spake thus:
> Having strftime() in DateTime.pm is also inconsis
issue (it's
> how dates are shown in your area) as opposed to a _language_ issue (the
> _names_ of things, regardless of display).
Fair enough. So would you suggest there be a DateTime::Language::* and
DateTime::Format::* for each non-latin1 language that DateTime may want
to handle?
Furt
On 1/4/03 12:47 pm, Daisuke Maki at [EMAIL PROTECTED] spake thus:
> Fair enough. So would you suggest there be a DateTime::Language::* and
> DateTime::Format::* for each non-latin1 language that DateTime may want
> to handle?
There'd be a ::Language module, but there'd only b
Iain 'Spoon' Truskett schreef:
> Yes. Though I have a curious case at present with a format module that
> just wants time and not date. The problem? DateTime objects require, at
> the very least, a specified year. Is this a problem? I don't know.
I have a calendar module that just handles dates, n
Eugene van der Pijll wrote:
> So I want
> to put all the DateTime.pm time stuff in a DateTime::Time module. All
> calendar modules that use the usual 24hour day can then inherit the
> time handling methods from DateTime::Time.
>
> It had not occurred to me to make it useable separately, to just
>
> I hate to say this but the language stuff may be deprecated in favor
> of locales...
Maybe eq 'is' in what will soon be released as DateTime '0.14'.
> But if you are willing to convert this to a locale definition I would
> like to ask you about some extra stuff for my DateTime::Format::Common
>
On Wed, 23 Jul 2003, Joshua Hoblitt wrote:
> You'll have to generate the locale files from the icu-xml descriptions
> (instructions are in the dist). Or if you wait about a week DT::Locale
> will hopefully be released to CPAN (crosses arms, looks at Dave).
Poof, done.
/*===
On Wed, 23 Jul 2003, Ben Bennett wrote:
> I hate to say this but the language stuff may be deprecated in favor
> of locales...
>
> But if you are willing to convert this to a locale definition I would
> like to ask you about some extra stuff for my DateTime::Format::Common
> parser. But I am not
On Wed, 23 Jul 2003, Ricardo SIGNES wrote:
> Is there a good way to determine whether to not to return Unicode
> strings? That's what I'm doing now, but obviously it's not so nice at
> the console. I don't do much serious work with Unicode in Perl, and
> there might be an obvious solution I don'
* Ben Bennett <[EMAIL PROTECTED]> [2003-07-23T21:33:05]
> On Wed, Jul 23, 2003 at 09:07:57PM -0400, Ricardo SIGNES wrote:
> > Tonight I /really/ didn't want to do any work, so I wrote
> > DateTime::Language::Esperanto.
> I hate to say this but the language stuff ma
* Dave Rolsky <[EMAIL PROTECTED]> [2003-07-24T00:39:01]
> On Wed, 23 Jul 2003, Ricardo SIGNES wrote:
>
> > Is there a good way to determine whether to not to return Unicode
> > strings? That's what I'm doing now, but obviously it's not so nice at
> > the console. I don't do much serious work wit
On Thu, 24 Jul 2003, Ricardo SIGNES wrote:
> What I was hoping for was a way to know whether it's useful to provide
> Unicode strings as results. In Esperanto, there are well-accepted
> conventions for ASCIIfying its Latin-3 letters. For example,
> "\x{0109}u" in Unicode would be written "cxu" i
Something I need for strptime. Any objections?
Out of interest, I note there are some commented out bits.
Is there any intention of having them work as would be intended?
Index: lib/DateTime/Language.pm
===
RCS file: /cvsroot/perl-d
05:26:02 -
@@ -14,6 +14,8 @@
- Allow from_epoch(), now(), and today() to accept a time_zone
parameter. Based on suggestions from Tim Bunce and Joshua Hoblitt.
+- Allow extraction of AM/PM string list from DateTime::Language classes.
+
[BUG FIXES]
- If a dateti
On Tue, 1 Apr 2003, Iain 'Spoon' Truskett wrote:
> How's the following? Give a 'yay' or 'nay' and I'll commit
> appropriately (I don't like touching other people's projects without
> an explicit "do it"; and, no, that's not a subtle way of disapproving
> your changes to the module I started; I tho
23 matches
Mail list logo
