On Sat, 7 Jul 2007, Bill Moseley wrote:
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.
Actually, it does change semi-regularly. Just recently (last 1-2 years)
some zones in Brazil were added.
However, I think they try to preserve backwards compatibility when a name
is dropped by turning it into a link to a real name (basically a symlink).
So really, you need to be more concerned about new zones being added. If
you have users in that area, the new zones may be important for them
because they usually reflect the most recent legal changes in that area.
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.
This is what I do in one app, though for my app zones are associated with
geographic regions, not users.
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
DateTime currently makes no effort to look at the locale-related env
vars. I suppose it could.
$ 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
DefaultLocale is a class method.
But if you're doing a webapp shouldn't this be a per-user setting anyway?
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?
There are various formatting strings in each locale that might be useful
if you have users in multiple locales. Search for "format" in the
DateTime::Locale docs.
Alternately, letting users pick a format they like probably works well.
Personally, I tend to like ISO8601 date format (YYYY-MM-DD), and I doubt
that any locale defaults to that ;)
-dave
/*===================================================
VegGuide.Org www.BookIRead.com
Your guide to all that's veg. My book blog
===================================================*/