Posted by Aren Cambre on October 18, 2007 at 10:11pm
6 followers
Jump to:
| Project: | Drupal core |
| Version: | 7.x-dev |
| Component: | base system |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (duplicate) |
Issue Summary
In various places, users and administrators encounter a drop down about time zones. At least in the English versions, these time zones should use well-known, named time zones and only use GMT deltas as a clarification.
Time zones are listed at http://en.wikipedia.org/wiki/List_of_time_zones.
Comments
#1
+1.
#2
Updating version.
#3
To do named timezones right requires PHP 5.2, which has a native library for timezone handling based on international standards. Drupal 6 supports PHP 4.3, so we can't rely on that.
However, Drupal 7 is slated to require PHP 5.2 and the date handling system is likely to get an overhaul next version. A switch to named timezones is very likely, IMO.
#4
Substantial code for this change already exists in the date_timezone module within the date module. http://drupal.org/project/date
#5
I would say that this is a duplicate of #11077: Introduce Daylight Saving Time for Drupal, merely because that issue has significantly more support than this one.
#6
#7
No, these are different issues. The other issue is specifically about DST. While there are comments concerning named time zones, the DST issue could be solved without naming any zones.
If it happens to solve this issue, then at that point let's close this one out. But until then, we need this to be open as a placeholder for this specific request.
#8
The correct solution to both issues is to use the DateTime object and its related utilities for all date handling. Then we get named timezones and timezone-sensitive DST all in one go.
#9
@Aren - I think you're getting into trivialities - while there is a module to use Javascript to get DST from the client, the entire focus of #11077: Introduce Daylight Saving Time for Drupal is to support named timezones as a basis for managing DST changes.
The PHP 5.2 date/time support is the current basis for this work. This will make PHP 5.2 a requirement for core, which will alienate a few folks, but I recall that PHP4 is hitting end-of-life anyway.
The patch is very close (finally) to getting in. I would say that the implementation is reasonably basic but sufficient for the needs of core. The Date module is a very nice piece of work and I would have no problem personally if this went to core instead - but we've been waiting a long time. 11077 is fairly clean, simple, and basic.
There's still room for the Date module in the scheme of things - both for the API and as a basis for Event, and perhaps as a plugin to support timezones on PHP4.x. But it's a bit of baggage to carry in core unless you have these special needs. I've got an issue open for re-writing format_date() #243129: Refactor format_date() to avoid multiple calls to date_format() once we get the timezones sorted since I find the brute force code offensive; but so far I seem to be alone in my disdain for it.
Once we have core timezones, we probably should start a topic at g.d.o. on how best to merge all these date/time efforts to clean up any duplication and work together to finally rid Drupal of the notorious "time isn't correct" bugs.
#10
This is a duplicate of the (poorly-named) #11077: Introduce Daylight Saving Time for Drupal which was fixed some time ago.