395287 - Event dialog: Cannot enable timezone option for ending time

Status: RESOLVED FIXED

(Calendar :: Dialogs, defect)

Description

[cmtalbert]

1. Open the Event Dialog
2. Use Options->Timezone to turn on the timezone support
3. Timezone picker appears next to the "start time" widget

== Expected ==
* Should have ability to also turn on timezone support for the "end time" widget.

== Actual ==
No way to turn on timezone setting for the end time widget.

== Use Case ==
Air travel - it usually starts and ends in different timezones.

Comment 1

[Christian Jansen]

Isn't that use case more or less an edge case? If I have to go on a business trip I usally mark the whole trip as 5 time repeating All Day Event. If I have meetings, I'll add these as standard events to the calendar. The flights are just a part of the trip. But this is only me :-)

Comment 2

[Michael Büttner (no reviews TFN)]

Just in order to clarify how this feature has been implemented - The dialog hides the ending timezone if the start- and end-timezone are equal. If both timezones are different they'll be displayed as expected. Setting either the end-timezone to be the same as the start-timezone or visa versa makes the end-timezone disappear as they are now equal.

Admittedly, there's no way to set the timezones to be different from each other once they are the same. For newly created events this is indeed what the user is initially is confronted with.

The reason why the dialog behaves as just described is the fact that it would be cumbersome to move the start- and end-timezone to some other timezone when the intention is to move both.

Comment 3

[cmtalbert]

Mickey, This makes perfect sense.  We just need a mechanism for the user to create an event that has a different end timezone from the start timezone.  I think the default behavior (hiding the end timezone if they are the same) is the proper and correct implementation.  

The "specify the timezone of the end time" mechanism could be hidden as a submenu of hte Options->Timezones drop down menu for the dialog.  And by default it should certainly be off (current behavior) 

And yes, this is an edge case, but an important one that we've been dinged for not supporting in the past.

Comment 4

[Michael Büttner (no reviews TFN)]

(In reply to comment #3)
> And yes, this is an edge case, but an important one that we've been dinged for
> not supporting in the past.
No doubt that this is an important case that we need to take into account. I just tried to explain what the current behavior is and why Christian and I decided to take that route. Furthermore, I find your suggestion on how to allow for defining an end timezone (that differs from the start timezone) a nice and elegant solution.

While we're tackling further use cases for timezones, this reminds me of the issue that we can't set the timezone(s) to be floating or UTC. It would probably  reasonable to address this in this bug as well.

Comment 5

[cmtalbert]

Sounds like a great plan!

Comment 7

[David Gessel]

This is one of my favorite complaints because airline itineraries list departure and arrival times in local time and I find myself doing the math in my head to block out the flight time on my calendar several times a week.  While it may be something of an edge case, it is a fat edge for people who want a workgroup calendar as many such people travel frequently.

It is also a nice feature differentiation to handle time zones well compared to most of the other calendar programs such as Outlook.

The following .ics file entry does the right thing...
DTSTART;TZID=/mozilla.org/20070129_1/America/New_York:20070514T140000
DTEND;TZID=/mozilla.org/20070129_1/America/Los_Angeles:20070514T150000

Comment 8

[Mike Beltzner [:beltzner, not reading bugmail]]

Oops, sorry, my bad, returning to the right component, awfully sorry about stomping your target milestone, please send hatemail to this address :(

Comment 9

[npandit]

I am not a developer, but love using T-bird and Lightning.  Can someone please address this bug so I can simply download it as an update or patch?  It would help tremendously.  Tks in advance.

Comment 11

[Steve Riley]

Sorry for the duplicate. Reading through the comments I can understand Michael's logic (comment #2), and Clint's solution is certainly one choice. How about this: go ahead and display links for both starting and ending timezone. If the link for the starting timezone is clicked and changed, then automatically change the ending timezone to match. That avoids the cumbersome behavior Michael describes. Then for those of us who live in the edge case, we can click the ending timezone to change that when necessary.

I'm new to the world of Thunderbird and very much like what I've seen so far. It took years to get this feature added to Outlook, and it finally behaves correctly in version 2007. It's the only Outlook feature I miss! Hope that we can see it added to Lightning soon.

Comment 12

[npandit]

I am not a developer and do not know how to implement any of these solutions... but all I can say is that many travelers like me that I know have refused to use Tbird mainly because of the lack of this feature.  Otherwise, they also loved all other aspects of it.  Hope someone takes up the implementation soon...

Comment 13

[npandit]

This has been around for 2 years now.  Wonder why noone takes it up.  If I was a developer, I would have done it.  The only reason for me to think of going over to Outlook...

Comment 15

[Philipp Kewisch [:Fallen][📱📆]]

Attachment: Fix - v1

I've changed the behavior slightly to match what the datetimepicker controls do:

* If you enable the timezone option, labels for both timezones are shown.
* Timezones are the same:
  - If you change the start timezone, then the end timezone changes too
  - If you change the end timezone, only the end timezone changes

* Timezones are different:
  - Changing the start or end timezone doesn't change any other option, just the
    respective timezone itself.

ssitter, I'd appreciate your feedback too.

Comment 16

[Markus Adrario [:Taraman]]

Comment on attachment 432523 [details] [diff] [review]
Fix - v1

Patch looks good and UI makes sense in my opinion.

One thing that comes to my mind here:
>+                if (!aDateTime || !aDateTime.isValid || gIsReadOnly || aDateTime.isDate) {
Do we really have to check for gReadOnly? If the event is Read Only I'm presented a coompletely different dialog. If I change the writable status of a calendar while the dialog is open, it is not updated and I get an error when saving.
Is there really a case, when I can open a rad-Only Item in the full eventDialog?

This would also apply to various other locations in this dialog.

Nvertheless: r=markus

Comment 17

[npandit]

Wow... I am so glad that you folks are addressing this issue.  When the patch is ready, can you please send me instructions on how to use it?  Pl note... I am not a developer.

Comment 18

[Philipp Kewisch [:Fallen][📱📆]]

(In reply to comment #16)
> Is there really a case, when I can open a rad-Only Item in the full
> eventDialog?
I imagine this is old code from before we had the summary event dialog. Check out the following:

* Make sure you have two writable calendars A and B.
* Open an event on calendar A.
* Switch the calendar dropdown to calendar B.
* Mark calendar A readonly
* Switch the dropdown back to calendar A.

Actual Result:
* Most (but not all) dialogs controls are disabled

I think we should de-cruft this in a different bug. Maybe we can add a notification bar at the top that tells the user that the calendar has been marked readonly and disable the save controls until that situation changes or the user selects a different calendar.

ssitter, I'd still appreciate your feedback on this bug.


npandit, please wait at least 24 hours, then you can test the nightly version of Calendar, it will contain this patch. Please report if this bug is fixed afterwards.


Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/6e69049c727c>

-> FIXED

Comment 19

[Philipp Kewisch [:Fallen][📱📆]]

Filed bug 553928 for the followup issue