1404737 - Event time shifts unpredictably in event dialog

Status: RESOLVED DUPLICATE of bug 1396639

(Calendar :: Dialogs, defect)

Description

[Merike Sell (:merike)]

At 22:48 I:
* Ctrl+I
* start time is set to 23 today and end time 0 at tomorrow
* I then click the down arrow next to start time and doubleclick 9
* as soon as focus leaves start time box by focusing another one start time displayed shifts to 07:34 (no idea why that specific one), end time remains at 10:00 but date shifts to today
* I try again by typing start time 9:00
* this time start time shifts to 07:34 again but end time also shifts on defocus to 08:34
* after two tries for a 9am event tomorrow I'm left with 07:34-08:34 today
* I focus start time again and then defocus entire event window
* when coming back to it start time is at 06:08 and end time 08:34
* I could go on but by now you probably understand what I mean by "unpredictably"

This was with a new profile set to Tallinn time automatically. Same thing happens when I try again 10 minutes later after a reboot just in case. I haven't been this puzzled about how time works in a very long time.

Comment 1

[[:MakeMyDay]]

I cannot reproduce this on Windows. You're on Linux, I assume (distro or vanilla)?

Does this also occur when disabling all extensions but Lightning (maybe some exetensions haven't followed the recent m-c time formatting changes we adopted in bug 1360915 )? Which date and time formatting option do you have configured at Aptions->Advanced->General?

Comment 2

[Merike Sell (:merike)]

Kubuntu 16.04 here. Only Lightning enabled in that profile. Application locale based (Estonian) as it was set by default.
I don't quite get what exactly is done at https://dxr.mozilla.org/comm-central/source/calendar/resources/content/datetimepickers/datetimepickers.xml#1771 and forward but time format for et ought to be hh:mm in general.

Comment 3

[[:MakeMyDay]]

Does the problem only exist in the datetime picker or also at other places where times are displayed? That kind of deviation maybe indicates something is going wrong in the underlying C code - times looked also that way before bug 1360915 was fixed.

Is this also an issue for you with a local build from tip?

Comment 4

[Merike Sell (:merike)]

I haven't seen anything this crazy elsewhere (so far). Although, I think date format is off somewhere as today pane uses dd.mm.yy where dd.mm.yyyy would be more natural. Would you happen to know without digging in somewhere deep if the format used there comes from OS settings, Lightning localization or elsewhere?

Will en-US local build do or is using et necessary for answering your second question?

Comment 5

[[:MakeMyDay]]

en-us will do - you can enforce your OS datetime formatting using the pref setting mentioned in comment 1.

Comment 6

[Merike Sell (:merike)]

Attachment: cal-trunk-errors.png

I'm afraid I don't even get to open the event dialog on trunk :(. Comm-central 0d7431731c87, mozilla-central 8dba4037f395.

Comment 7

[Merike Sell (:merike)]

FWIW, nightly regression range for me is https://hg.mozilla.org/comm-central/pushloghtml?fromchange=4a0c88a88c3d919cf13960ceda498d7410429505&tochange=ee00fc1004edaec247589a20c298cf54d206f43c
Whether I have it set to application locale or regional settings based time formatting does not make a difference.

Comment 8

[[:MakeMyDay]]

Merike, just to be sure: this happens for you even with a local build or a Mozzilla vanilla package? We have a similar report in bug 1396639.

Comment 9

[Merike Sell (:merike)]

That sounds similar enough for duping. Yes, it was broken for me with a local en-US build. Regression range came from trying nightlies. Maybe an intl bug of sorts on Linux?