801838 - Manually setting time displays incorrect time/date

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::Settings, defect, P2)

Description

[[:Cww]]

Setting the time manually (because automatic doesn't seem to work) seems to set the wrong time and/or not actually work.

STR:

Go to Settings > Date & Time

Pick a timezone (Los Angeles (Pacific))

Set a Date (whatever works). Note the date displayed does not reflect the date you selected.

Set a Time (whatever works). Note the time displayed does not reflect the time selected. Also, the system time (in the notification bar) neither reflects the time displayed in the setting NOR the time you chose.

Comment 1

[Gene Lian (I already quit Mozilla)]

Ian, we need Gaia experts to confirm this. Is this issue just what we're discussing about recently?

1. Bug 801096 for immediately enabling the auto-update.
2. Bug 790499 for reflecting the correct system time.

The above-mentioned items are exactly what we need to tackle for this issue. Right? Anything else?

Comment 2

[[e-mail], [e-mail]]

Hi Gene,

Yes, the above two issues blocking time display after set a new date/time.
If you're not sure the value of new date/time set to the platform,
you could add a console in gaia/apps/settings/js/date_time.js as following.

Line 91: console.log('== newDate == ' + newDate.toLocaleFormat('%Y-%m-%d-%H:%M'));

Comment 3

[Gene Lian (I already quit Mozilla)]

Thanks for the confirmation! Should be able to upload a patch for Bug 801096 later.

Comment 4

[Shelly Lin [:shelly]]

Hi Ian,

I happened to take a look at this issue, it seems like in gaia/apps/settings/js/date_time.js, the listener of timePickerChange() has been called twice for a confirm change, which cause setTime() being called twice.

Comment 5

[Gene Lian (I already quit Mozilla)]

(In reply to Shelly Lin [:shelly] from comment #4)
> Hi Ian,
> 
> I happened to take a look at this issue, it seems like in
> gaia/apps/settings/js/date_time.js, the listener of timePickerChange() has
> been called twice for a confirm change, which cause setTime() being called
> twice.

I could reproduce the same bug. The redundant calls would make terrible result, because navigator.mozTime.set() would be called twice to adjust the system clock time by double time-diffs. Supposing the time now is 16:20, if you desire to set time to 16:10, the final setting time will become 16:00.

Comment 6

[[e-mail], [e-mail]]

Yes, I encounter the problem during develop the feature.
I think that could be another issue for fired event twice from "input" tag.
We could create an issue for the problem.
Bug 802073 - Receive input event twice from input tag type:time and type:date

Comment 7

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Ian Liu [:ianliu] from comment #6)
> Yes, I encounter the problem during develop the feature.
> I think that could be another issue for fired event twice from "input" tag.
> We could create an issue for the problem.
> Bug 802073 - Receive input event twice from input tag type:time and type:date

Can the set time part in Settings app workaround with this issue first?

Comment 8

[[e-mail], [e-mail]]

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #7)
> (In reply to Ian Liu [:ianliu] from comment #6)
> > Yes, I encounter the problem during develop the feature.
> > I think that could be another issue for fired event twice from "input" tag.
> > We could create an issue for the problem.
> > Bug 802073 - Receive input event twice from input tag type:time and type:date
> 
> Can the set time part in Settings app workaround with this issue first?

Yes, we can set a timer to avoid duplicated input event in one sec.

Comment 9

[Gene Lian (I already quit Mozilla)]

Thanks Ian! It seems this issue is due to a general bug in input tag type. Let's work it around and address this issue at bug 802073.

Comment 10

[[e-mail], [e-mail]]

Attachment: workaround to avoid received input event twice

Workaround for the issue:
Bug 802073 - Receive input event twice from input tag type:time and type:date

It will help to let Bug 801838 keep investigation.
Bug 801838 - Manually setting time displays incorrect time/date

Comment 11

[[e-mail], [e-mail]]

Hi Gene,

For your test, you could modify the style of opacity to 1.
(gaia/apps/settings/style/lists.css  line: 160)
Then, you can see the original input tag in setting date/time section.
It will help you to check the value which is picked by the date/time picker.
Thanks.

Comment 12

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Comment on attachment 672219 [details]
workaround to avoid received input event twice

Please rewrite the work based on the offline discussion.

Comment 13

[[e-mail], [e-mail]]

Comment on attachment 672219 [details]
workaround to avoid received input event twice

><html>
>   <head>
>   <meta http-equiv="Refresh" content="2;
>url=https://github.com/mozilla-b2g/gaia/pull/5866">
>   </head>
>   <body>
>     Redirect to pull request 5866
>   </body>
></html>

Comment 14

[[e-mail], [e-mail]]

Comment on attachment 672219 [details]
workaround to avoid received input event twice

Workaround for the issue:
Bug 802073 - Receive input event twice from input tag type:time and type:date

It will help to let Bug 801838 keep investigation.
Bug 801838 - Manually setting time displays incorrect time/date

Refine to avoid settings date/time delay 1 second

Comment 15

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Comment on attachment 672219 [details]
workaround to avoid received input event twice

r=me.

Comment 16

[Tim Guan-tin Chien [:timdream] (please needinfo)]

https://github.com/mozilla-b2g/gaia/pull/5866

Workaround merged.

Comment 17

[:Gavin Sharp [email: [e-mail]]]

How does this relate to bug 796270?

Comment 18

[Gene Lian (I already quit Mozilla)]

(In reply to :Gavin Sharp (use [e-mail] for email) from comment #17)
> How does this relate to bug 796270?

It smells like the same thing.

Comment 19

[Andrew Overholt [:overholt]]

Should we dupe this to bug 796270?  What do you think, Gene?

Comment 20

[Gene Lian (I already quit Mozilla)]

Hi Andrew! Thanks for pointing this out! The history is:

Bug 801838 and Bug 796270 are aimed for solving the same issue. Actually, they're both solved by a work-around solution in comment #16 within this issue. However, their actual root cause is:

Bug 802073 - Receive input event twice from input tag type:time and type:date

So I suggest we can close both Bug 801838 and Bug 796270 for now. Meanwhile, keep track of the Bug 802073.

Comment 22

[Tim Taubert [:ttaubert] (inactive)]

Can anyone actually confirm this solution? Setting time still doesn't work for me if I don't tap *directly* on the currently selected value. If I just swipe the time without tapping in the middle of the value selector it doesn't apply the selected time. Pretty sure a focus issue.

Comment 23

[Tim Taubert [:ttaubert] (inactive)]

Wait, the above information isn't correct but for some reason, turning the wheel and tapping the selected value sometimes makes a difference and the value is applied.

Comment 24

[Gene Lian (I already quit Mozilla)]

Weird... it works for me. Let's ask qa for a support.

Comment 25

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

## Environment :
Unagi phone, build 20121031073004
2012-10-31 10:23:10

It sometimes works for me and sometimes doesn't.

If I set the time to one hour behind, hit cancel... then go back and set it to the same again and hit ok, it sometimes does not set the time.

Does changing the time mess with the idle time, timeout, or handle timing?

Comment 26

[Tim Taubert [:ttaubert] (inactive)]

I figured out what's wrong. It's explained in bug 802073 comment #16 and will be fixed by bug 802073.

Comment 27

[Gene Lian (I already quit Mozilla)]

Thanks Tim and Naoki for investigations! Well, let's keep this one opened before bug 802073 is fixed. At that time, we need to back out the work-around at comment #16 before closing this issue.

Comment 28

[Tim Taubert [:ttaubert] (inactive)]

Attachment: Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/6239

Pointer to Github pull-request

Comment 29

[Tim Taubert [:ttaubert] (inactive)]

Comment on attachment 679105 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/6239

This removes the workaround we landed for this bug. We should not merge this before bug 802073 lands on Aurora.

Comment 30

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Comment on attachment 679105 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/6239

r=me, thanks!!

Comment 31

[Tim Guan-tin Chien [:timdream] (please needinfo)]

https://github.com/mozilla-b2g/gaia/pull/6239

Comment 32

[J Zimbrick]

Issue appears fixed for the most part on Unagi build 20130103070201.

Date and time are accurately changed if the user wants to do so, but only within a certain timeframe.

For some reason setting the year to 1979 or earlier, or 2039 or later will set the year, date, and time to something else than what the user specified. (Keeps setting mine to 01/01/1970 at 1:00 AM)

 Seems like a pretty minor bug since I can't really think of a reason someone would need to set their clock so far back or forward, but I'll log a bug on it anyway and mark this one as verified.

Verifying as fixed.