This patch adds locale names to the timezone offsets provided by system.module.

Currently, the function returns an array with offsets for keys and formatted 'local' times for the values. With this patch, the function will return an associative array with two keys 'times' and 'locales'. Each key has an array with the offset values for keys, and thier associated local time value, or locale name.

This patch provides a standard place to retrieve timezone values when developing with them, improves useability when displaying timezone select boxes, and updates the timezone offset values. This patch will be utilized immediately by event.module, which currently uses an almost equivelant function, event_zonelist.

CommentFileSizeAuthor
system_6.patch4.87 KBcrunchywelch
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Dries’s picture

Does anyone thinks is worth including in core? If it is only useful for one or two modules (eg. the event module), it would be easy enough to include this table in those modules.

killes@www.drop.org’s picture

Yes, I think this patch is usefull. It makes the time zone selector better readable and improves usability. This selector is used for both the cetral system time and the user's time zone (if that is enabled).

TDobes’s picture

It might be nice to have a more readable timezone list, but this might cause some users to assume that Drupal deals with daylight savings time. For example, the majority of the "US Central" timezone (where I live) switches for DST, so I would expect that, to most people, "US Central" means "Central Prevailing Time" (CST or CDT depending on the time of the year). I can say for certain that, had I not previously seen the code, this would be confusing to me. On the other hand, the numeric values (as we have now), suggest that a constant offset from GMT is used.

If we really want to include these named timezones, I think we should mention or indicate in some way that Drupal does not deal with DST. It's unfortunate that implementing international DST is so complicated.

So... I don't mind the named timezones, but I think that, if we do commit this patch, it should be indicated in the UI that Drupal will not adjust its clock automatically for daylight savings.

tostinni’s picture

IMHO, I pretty like the way windows defines the time zone, it allows various choices (I guess regarding of the daylight savings) for each timezone. Also it gaves cities as reference, because here in Mexico, I'm not sure that everybody knows that we are in US Central time zone ;)

Worth the include in core, but maybe with a little more precision.

jjeff’s picture

I'd like to see this in the core.

1) Much better usability for anyone needing to choose time zone.
2) It would be nice to have this standardized accross all Drupal modules and not leave each module developer trying to find the associated name for each time zone. (I've done it once myself).

One of Drupal's great strengths is it's internationalization. With internationalization comes time zone issues. And we who are further from the meridian often don't know our offset other than "Eastern", "Central", "Mountain", or "Pacific".

But it looks like the patch does away with the numerical listing altogether. My preference would be for the array values to contain the numerical version of the timezone offset as well. Example:

-6 => t('US Central (-6)')

-Jeff

moshe weitzman’s picture

Status: Needs review » Needs work

yeah, listing one city per time zone really doesn't cut it. neither windows norOSX do it like that. basically, i think this adds complexity without enough value.

if you guys haven't seen the autotimezone module, check it out. i have been talking about this imjplementation for 2 years and finally someone built it. zero effort on the part of the user to get proper time zone with daylight savings - http://cvs.drupal.org/viewcvs/drupal/contributions/modules/autotimezone/

Jaza’s picture

Version: x.y.z » 4.7.x-dev
Status: Needs work » Closed (fixed)

@Tdobes:

the majority of the "US Central" timezone (where I live) switches for DST, so I would expect that, to most people, "US Central" means "Central Prevailing Time" (CST or CDT depending on the time of the year). I can say for certain that, had I not previously seen the code, this would be confusing to me. On the other hand, the numeric values (as we have now), suggest that a constant offset from GMT is used.

I agree with this statement. Displaying locale names to the user instead of numeric GMT offsets implies that the system has DST support, so I don't think that this patch should go in. Instead, let's implement displaying locale names as part of a larger DST/locale/timezone improvement patch for Drupal (for which there are numerous other existing issue threads). Also, -1 to the massive array in system.module - surely there's a better place to put locale names.

Closing issue.