$VERSION = '0.37';
I have a few general I18N questions. Perhaps you have some
suggestions for best practices.
I currently have a timezone table in my database and my "users" table
references the timezone table via a timezone column.
I populate the timezone table with DateTime::TimeZone->all_names.
When a user sets their timezone they must pick from what's available
in the timezone table.
Is the list of timezones reasonably static? I assume it doesn't
change very often.
My other option is to use a text column type and store the timezone
strings in each row of the users table. That way I won't have to
update my timezone table if DateTime::TimeZone->all_names returns new
zones. Uses a bit more space in each row of the users table.
I then use this timezone string in my (TT) templates:
[% CALL login_time.set_time_zone( user.timezone ) %]
Now, I'm not sure I'm understanding how locales work in DateTime.
$ LC_ALL=es_ES date
sáb jul 7 07:33:03 PDT 2007
Should these be localized?
$ LC_ALL=es_ES perl -MDateTime -le 'print DateTime->now->strftime("%A %c")'
Saturday Jul 7, 2007 2:34:09 PM
$ LC_ALL=es_ES perl -MDateTime -le 'DateTime::DefaultLocale("es_ES"); print
DateTime->now->strftime("%A %c")'
Saturday Jul 7, 2007 2:40:43 PM
$ LC_ALL=es_ES perl -MDateTime -le 'DateTime::DefaultLocale("es_ES"); print
DateTime->now->subtract( months => 2 )->strftime("%A %c")'
Monday May 7, 2007 2:44:25 PM
I'm wondering how to localize dates. In my web application's
templates I have a number of "virtual" methods, so I can write:
[%
login_time.timestamp_full; # Monday May 7, 2007 2:44:25 PM PST
login_time.timestamp_compact; # 2007-05-07 14:44
login_time.date_compact # 2007-05-07
# and so on.
%]
Where those are just preset strftime strings. This seems like a sane
approach? Or do you have a different method?
Thanks,
--
Bill Moseley
[EMAIL PROTECTED]
