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)
Firefox OS Graveyard
Gaia::Settings
Tracking
(blocking-basecamp:+)
VERIFIED
FIXED
blocking-basecamp | + |
People
(Reporter: cww, Unassigned)
References
Details
(Keywords: unagi)
Attachments
(2 files)
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.
Updated•12 years ago
|
Assignee: nobody → slin
Comment 1•12 years ago
|
||
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•12 years ago
|
||
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•12 years ago
|
||
Thanks for the confirmation! Should be able to upload a patch for Bug 801096 later.
Comment 4•12 years ago
|
||
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.
Updated•12 years ago
|
Assignee: slin → nobody
Comment 5•12 years ago
|
||
(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.
Updated•12 years ago
|
OS: Mac OS X → All
Hardware: x86 → All
Comment 6•12 years ago
|
||
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
Comment 7•12 years ago
|
||
(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•12 years ago
|
||
(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•12 years ago
|
||
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•12 years ago
|
||
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)
Comment 11•12 years ago
|
||
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•12 years ago
|
||
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 13•12 years ago
|
||
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 14•12 years ago
|
||
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•12 years ago
|
||
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)
Comment 16•12 years ago
|
||
https://github.com/mozilla-b2g/gaia/pull/5866
Workaround merged.
Comment 17•12 years ago
|
||
How does this relate to bug 796270?
Comment 18•12 years ago
|
||
(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.
Comment 19•12 years ago
|
||
Should we dupe this to bug 796270? What do you think, Gene?
Flags: needinfo?(clian)
Comment 20•12 years ago
|
||
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)
Updated•12 years ago
|
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Updated•12 years ago
|
Component: General → Gaia
Comment 22•12 years ago
|
||
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•12 years ago
|
||
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•12 years ago
|
||
Weird... it works for me. Let's ask qa for a support.
## 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•12 years ago
|
||
I figured out what's wrong. It's explained in bug 802073 comment #16 and will be fixed by bug 802073.
Comment 27•12 years ago
|
||
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 28•12 years ago
|
||
Pointer to Github pull-request
Comment 29•12 years ago
|
||
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 30•12 years ago
|
||
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+
Updated•12 years ago
|
Component: Gaia → Gaia::Settings
Comment 31•12 years ago
|
||
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → FIXED
Comment 32•12 years ago
|
||
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.
Description
•