Thank you for raising this issue. While we can see how this feature would be useful, we have no plans to implement it in the foreseeable future. In order to set expectations, we're closing this request now.

Thanks again for your idea.

Bill Arconati,
Confluence Group Product Manager

Hmm, perhaps we should show the current time in the menu as well as the offset and DST status so there's less confusion here.

I know that my colleagues in SF have just switched to daylight savings time in the past few weeks. Occasionally the schedule for these changes is modified by the relevant government department, and Java needs to be updated to reflect this. You should check that you're running the latest patch version of Java, which usually includes the latest DST settings for time zones. I'm not sure where it applies, but on some platforms there are also operating system time zone files that might need to be updated.

As I mentioned above, selecting the "Pacific Time" in Confluence is precisely the same as "America/Los_Angeles" in any other Java application. So if the DST transition or time is messed up, it's unlikely to be a problem that we can fix in the product.

Thanks for the feedback.

Thanks for getting back to me.

I know Tijuan and LA ought to be the same, but I was getting material timestamped an hour off. I guess it was magical thinking that made me hope that Pacific/Tijuana was maybe handled differently. On the person account settings page the menu still shows Tijuana as GMT -8 even though it should be -7.

The funny thing is, other than the erroneous (or maybe just misleading) information in the TZ setting menu, I was getting wrong timestamps yesterday, but it looks OK today. I upgraded 4 plugins, so maybe something got reset. Or maybe not. I'll keep an eye out and see if I notice it happening again.

John, isn't LA in the US "Pacific Time" time zone? As we'll see below, the actual time zone selected when you choose "Pacitic Time" is Los Angeles, so you should be fine if you choose this. Apologies for any confusion.

We use a list which is very similar to Microsoft Windows (we pretty much copied it), where we group the underlying time zone IDs (e.g. America/Los_Angeles) to reduce a lot of unnecessary duplication in the list and display a well-known zone name (like Pacific Time, Central Time, etc.) or a list of cities.

If you want to fiddle with the list in Confluence, the list of selectable time zones are in com/atlassian/confluence/core/timezones.properties in the main Confluence JAR file, WEB-INF/lib/confluence-x.x.x.jar, and the conversion of those names into localised time zone names is in ConfluenceActionSupport.properties in the same location.

In your case, the Pacific Time time zone is in fact the underlying America/Los_Angeles time zone. In timezones.properties:

time.zone.list=\
        GMT, \
        ...
        America/Los_Angeles, \
        ...

In ConfluenceActionSupport.properties:

time.zone.America.Los.Angeles=Pacific Time (US & Canada), Tijuana

The code is converted into an i18n key by changing all non-letter characters to dots.

I'm using Confluence 4.1.5 and the problem is still here. I notice that the time zone preference uses a reduced set of US time zones. Normally I use America/Los_Angeles with other software and that works, but the only West Coast TZ I see available is Pacific Time/Tijuana. Is there a way to jam in the LA TZ manually, or should I choose a -7 TZ until we go back to -8 in the Autumn?

Thanks for the comments, folks.

Confluence has a list of time zones provided by Java, and will take into account daylight savings time (DST) in time zone conversions throughout the application. The most recent patched version of Java may be needed for correct DST handling, as the start and end dates for DST in each location change from time to time.

However, the offsets displayed in the time zone selection UI don't take into account any current DST offset. Rather the time zone is displayed with the official (non-DST) offset from GMT. I'm understanding this improvement request as asking for the time zone drop-down to display offsets taking into account DST.

For the calendar plugin itself, we'll continue tracking that specific issue as CAL-203.

Filed bug (CAL-203) about this: http://developer.atlassian.com/jira/browse/CAL-203

I was just researching the same issue. Right now it is 1:40 PM here. I'm looking at a page that says it was last modified on Nov 01, 2007 12:29, but the Last Updated page shows that it was updated 12 mins ago.

This is confusing.

I agree that a calendar tool without DST support is really problematic.

The fact that the timezone in the calendar does not support DST also means that event creators tend to use the wrong time when entering the event (they use their time, e.g. EDT = GMT-4 although the interface lists EST = GMT-5 as their timezone), which confuses the other users who never quite know whether the time should be interpreted as being in the timezone listed (GMT-5) or in their current timezone (GMT-4 in our example).

A calendar tool without DST support is really problematic.

Calendar screenshot of an event happening at 11am CDT.