Re: "The default datetime format for the object’s locale"
Short answer: As of DateTime v0.72 on my local machine, %c is not directly configurable. A little more info: %c is hardcoded to use the locale's `datetime_format_default` (search for "strftime_patterns" in DateTime.pm) DateTime::Locale::ko does not override 'datetime_format_default'. Nor does it override 'default_date_format_length', or 'default_time_format_length', both of which default to 'medium' (see DateTime::Locale::root.) DT:Loc:ko's "medium" date/time formats are "\.\ M\.\ d\." and "a\ h\:mm\:ss", which is why you get the output below. So without modifying/overriding DateTime::Locale::ko, or dropping your use of %c in favor of a custom formatter, it may be difficult to fix your problem. If the locale's definitions for the 'medium' formats are wrong/outdated (see http://cldr.unicode.org/index/downloads) you could propose an update to the locale class itself, but I am unsure of the "official" way to do this. -Nate On Wed, Oct 24, 2012 at 2:36 AM, Bill Moseley wrote: > We have been using formats %c, %x and %X for localizing dates based on > Locale. Mostly works ok, but for Korean we are getting this: > > 2012. 10. 18. 오후 4:09:05 > > > where (I've been told) we would like this format: > > 2012년 10월 22일 월요일 오후 01:44 PDT > > > Is this formatting done in DateTime? I'm wondering how we can set the > default format used by %c for a given locale. > > In a web app what we are currently doing is > setting DateTime->DefaultLocale() per request. The DateTime objects are > inflated from database rows with DBIC. > > -- > Bill Moseley > mose...@hank.org
DateTime::Locale::ja, multiple datetime formats
Hello!
In CLDR version 1.7.1 [1] (on which DateTime::Locale::ja v0.45 is
based) the 'full' and 'long' datetime formats (incorrectly) differed
from the 'medium' and 'short' ones as follows:
full/long: "{1}{0}"
medium/short: "{1} {0}" (space between date and time)
(As of this bugfix[2] included in CLDR v21, all of the formats in
DT:Loc:ja correctly include the space.)
DT:Loc:Base's _make_datetime_format method does not accommodate
different datetime format: it simply uses the result of
$self->datetime_format (which, for DT:Loc:ja, is hardcoded to
"{1}{0}".)
I am not sure if any other locales require multiple datetime styles,
but it is apparent from CLDR's XML that this is supported.
Has anyone else seen a need for multiple datetime style support? Would
it be worthwhile for me to submit a patch for it?
Thanks much,
-Nate
[1] http://www.unicode.org/repos/cldr/tags/release-1-7-1/common/main/ja.xml
[2] http://unicode.org/cldr/trac/ticket/4220
Re: DateTime performance
++ to using precomposed TZ object (as you observed, supplying only the
name as a string still results in lengthy DT:TZ object creation
overhead.)
If you use them, I would also precompose any necessary Formatter or
Locale objects.
Depending on how you're parsing the date strings and composing the DT
objects, `local $Params::Validate::NO_VALIDATION = 1;` can speed
things up for you.
If you're using a DateTime::Formatter class to parse strings into DT
objects for you, you might investigate using your own regex to chop up
the string and call DT->new directly.
This code (including comments) is from early 2011 and I unfortunately
do not have benchmark data handy:
# NOTE: This method is faster than using DateTime::Formatter::MySQL
# NOTE2: It's also faster than `split m#[ /:T-]#`
$timestamp =~ m!^
(?:\s+)?(\d{4,4})[/-](\d{1,2})[/-](\d{1,2}) # Required date portion
(?:[T\s](\d{1,2}):(\d{1,2}):(\d{1,2}))? # Optional time portion
(?:\s?([\w/\+:]+))? # Optional timezone
$!x;
my ($y, $m, $d, $hr, $min, $sec, $tz) = ($1, $2, $3, $4, $5, $6, $7);
On 4 May 2012 13:20, Philipp K. Janert wrote:
> On Thursday 03 May 2012 02:14:45 you wrote:
>> > From: Philipp K. Janert [mailto:jan...@ieee.org]
>> > Sent: Wednesday, 2 May 2012 8:29 AM
>> >
>> > Question:
>> >
>> > When using DateTime for a large number of
>> > instances, it becomes a serious performance
>> > drag.
>>
>> ...
>>
>> > Is this expected behavior? And are there access
>> > patterns that I can use to mitigate this effect?
>> > (I tried to supply a time_zone explicitly, but that
>> > does not seem to improve things significantly.)
>>
>> Hi Phillip,
>>
>> My #1 tip is to pre-prepare/cache the DateTime::TimeZone object and pass it
>> in to each creation of a DateTime object (via whatever mechanism you're
>> using to do that). I have seen a case where we were using time_zone =>
>> 'local' in a reasonably tight datetime object creation loop and saw
>> significant speed increases just by cutting out that chunk of processing.
>>
>> In hindsight that was a silly thing to do but it became an easy win :-)
>>
>> I apologise if this is what you meant by supplying a time_zone explicitly
>> in your comment above.
>
> I have tried to specify the timezone explicitly as a string:
> $dt = DateTime->new( ..., time_zone => "America/Chicago" )
> which does not seem to help, but I have not tried to do:
> $tz = DateTime::TimeZone( 'America/Chicago' )
> $dt = DateTime->new( ..., time_zone => $tz )
>
> I'll try that the next time I have to process one of my data
> sets again. ;-)
>
> Thanks for the hint.
>
>>
>> I can't recommend using a tool like NYTProf highly enough on a run of your
>> tool to spot the low hanging fruit. See
>> https://metacpan.org/module/Devel::NYTProf
>>
>> Cheers,
>>
>> Andrew
Truncating to 'week' does not take Locale's first_day_of_week into account
Hello! I noticed that the truncate method uses $self->day_of_week instead of $self->local_day_of_week in its "week" calculation. I'm currently working around this by reimplementing the functionality in my own code, but if a user has setup a Locale with, e.g. Sunday as first_day_of_week, then it seems like that value should be used. Would it be worthwhile for me to submit a patch that checks for the existence of $self->locale and uses local_day_of_week if a Locale is set? Or is this a behavior that I should continue to work around on my own? Thanks much, - N. Heinrichs
