Closed Bug 801838 Opened 12 years ago Closed 12 years ago

Manually setting time displays incorrect time/date

Categories

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

Product:
Firefox OS Graveyard
Component:
Gaia::Settings
Type:
defect

Tracking

(blocking-basecamp:+)

Status:
VERIFIED FIXED
Project Flags:
blocking-basecamp +

People

(Reporter: cww, Unassigned)

References

Details

(Keywords: unagi)

Attachments

(2 files)

workaround to avoid received input event twice
185 bytes, text/plain
timdream
: review+
Details
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/6239
355 bytes, text/html
timdream
: review+
Details 
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.
Keywords: unagi
Assignee: nobody → slin
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?
Blocks: b2g-system-time
blocking-basecamp: --- → ?
Depends on: 801096, 790499
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'));
Thanks for the confirmation! Should be able to upload a patch for Bug 801096 later.
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.
Assignee: slin → nobody
(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.
OS: Mac OS X → All
Hardware: x86 → All
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
blocking-basecamp: ? → +
Priority: -- → P2
(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?
(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.
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.
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
Attachment #672219 - Flags: review?(timdream+bugs)
Attachment #672219 - Flags: feedback?(clian)
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 on attachment 672219 [details]
workaround to avoid received input event twice

Please rewrite the work based on the offline discussion.
Attachment #672219 - Flags: review?(timdream+bugs)
Attachment #672219 - Flags: feedback?(clian)
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>
Attachment #672219 - Flags: review?(timdream+bugs)
Attachment #672219 - Flags: feedback?(clian)
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 on attachment 672219 [details]
workaround to avoid received input event twice

r=me.
Attachment #672219 - Flags: review?(timdream+bugs)
Attachment #672219 - Flags: review+
Attachment #672219 - Flags: feedback?(clian)
How does this relate to bug 796270?
(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #17)
> How does this relate to bug 796270?

It smells like the same thing.
Should we dupe this to bug 796270?  What do you think, Gene?
Flags: needinfo?(clian)
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.
Flags: needinfo?(clian)
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Component: General → Gaia
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.
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.
Weird... it works for me. Let's ask qa for a support.
Status: RESOLVED → REOPENED
Keywords: qawanted
Resolution: FIXED → ---
## 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?
I figured out what's wrong. It's explained in bug 802073 comment #16 and will be fixed by bug 802073.
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.
Keywords: qawanted
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.
Attachment #679105 - Flags: review?(timdream+bugs)
Comment on attachment 679105 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/6239

r=me, thanks!!
Attachment #679105 - Flags: review?(timdream+bugs) → review+
Component: Gaia → Gaia::Settings
https://github.com/mozilla-b2g/gaia/pull/6239
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: