Commit 6e96f984 authored by Robert Rollins's avatar Robert Rollins

Corrected the README's description of Date's "time zone handling" setting.

Upon further research, I discovered that my previous write-up about this
setting was incomplete and partially incorrect. I also discovered the
glaring bugs in the "Date's time zone" setting, so I added a warning against
using it.
parent 23a88cb3
...@@ -154,31 +154,46 @@ IMPORTING AN ICAL FEED FROM ANOTHER SITE USING Feeds ...@@ -154,31 +154,46 @@ IMPORTING AN ICAL FEED FROM ANOTHER SITE USING Feeds
Remember, you have to map the UID source to the GUID target, and make it Remember, you have to map the UID source to the GUID target, and make it
unique, or your imports won't work! unique, or your imports won't work!
IMPORTANT NOTE ABOUT THE DATE FIELD TIMEZONE SETTING:
Date fields have a setting called "Time zone handling" which determines how dates ===============================================================================
stored in the field are displayed to users. The Date module actually saves your IMPORTANT NOTE ABOUT THE DATE FIELD TIMEZONE SETTING
events' dates in the UTC timezone (a.k.a. GMT, or Greenwich Mean Time), then ===============================================================================
performs a conversion on them when the date is displayed to the user. Date fields have a setting called "Time zone handling" which determines how
This conversion is performed differently depending on these five options: dates are stored in the database, and how they are displayed to users.
- "Site's time zone" displays the date in the "Default time zone" that's set - "Site's time zone" converts the date to UTC as it stores it to the DB. Upon
on the Regional Settings configuration page of your site. display, it converts the date to the "Default time zone" that's set on your
- "Date's time zone" displays the date in the timezone that it was specified as site's Regional Settings configuration page (/admin/config/regional/settings).
within the imported iCal feed. - "Date's time zone" stores the date as it is entered, along with the timezone
- "User's time zone" converts the date to the timezone set on the current name. Upon display, it converts the date from the stored timezone into the
user's account. site's default timezone. Well, I'm pretty sure it's *supposed* to do that, but
- "UTC" converts the date to the UTC timezone, regardless of which timezone the code behind this setting is very buggy. DO NOT USE THIS SETTING.
it was imported with. - "User's time zone" converts the date to UTC as it stores it to the DB. Upon
- "No time zone conversion" is very different from the others. This one display, it converts the date to the current user's timezone setting.
actually changes the way the date is saved in the database, storing it in - "UTC" converts the date to UTC as it stores it to the DB. Upon display, it
either the current user's timezone or the site's default time zone. It then performs no conversion, showing the UTC date directly to the user.
performs no timezone conversion when the date is displayed. - "No time zone conversion" performs no conversion as it stores the date in
the DB. It also performs no conversion upon display.
In most cases, you'll want your Date fields on imported event nodes to use
"Date's time zone". That's the only one that will ensure that the timezone set The appropriate setting to choose here will depend upon how you want times to
in the iCal feed will be the timezone in which the date is displayed to users. be displayed on your site. The best setting *would* be "Date's time zone",
but since that setting is so buggy, I must recommend against it. Instead,
If your Date field already has data in it, though, you won't be able to change I'd suggest using "Site's time zone" for sites which host events that are
this setting. In that case, "Site's time zone" (the default) is often adequate. mostly in the same timezone (set the site's default timezone appropriately).
This works just right for local users of your site, and will be the least
confusing for users who live in a different timezone.
For sites which store events that take place in multiple different timezones,
the "User's time zone" setting is probably the most appropriate. Most users will
presumably be tuning in to your events online or on TV (since many take place
far away from them), which means they'll want to know what time the event occurs
in their local timezone, so they don't miss the broadcast.
If your Date field is already set to "Date's time zone", you won't be able to
change it, because that setting uses a different table schema than the others.
Since "Date's time zone" is very buggy, I'd strongly recomend deleting the
field and recreating it with a different setting. This will delete all the
dates in existing event nodes which use this field.
=============================================================================== ===============================================================================
HOW TO FIX THE "not a valid timezone" ERROR HOW TO FIX THE "not a valid timezone" ERROR
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment