Closed Bug 1165078 Opened 9 years ago Closed 9 years ago

[Date&Time] First observance of 'Time Zone' when 'Date & Time' is set to Automatic displays placeholder: 'America/New_York'

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(b2g-master affected)

RESOLVED DUPLICATE of bug 833393
Tracking Status
b2g-master --- affected

People

(Reporter: onelson, Unassigned)

Details

(Whiteboard: [3.0-Daily-Testing])

Attachments

(3 files)

Attached image 2015-05-14-17-56-53.png (deleted) —
Description:
When the user first observes the automatic timezone observed by their 'Date & Time' Settings in their phone, they may notice that the timezone displays errorneous characters, such as an underscore. On initial flash and loading into Settings->Date&Time, the UI is observed as showing 'America/New_York'. If the time setting is toggled from Manual --> Automatic, it will adjust to UTC-07:00 which appears accurate.


Repro Steps:
1) Update a Flame to 20150514010203
2) Open the Settings app
3) Navigate to 'Date & Time'
4) Observe 'Time Zone'

Actual:
Timezone displays placeholder characters. Ex: 'America/New_York'

Expected:
Timezone displays accurate characters



Environmental Variables:
----------------------------------

Device: Flame 3.0
Build ID: 20150514010203
Gaia: 338f66e6a96491d2f5854b188c6b141ceb690d97
Gecko: 1fab94ad196c
Gonk: 040bb1e9ac8a5b6dd756fdd696aa37a8868b5c67
Version: 41.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0
*********************************
Issue DOES NOT REPRO on 2.2 for flame devices, new design:
Results: Automatic Setting of Date & Time does not display a specific Timezone

Device: Flame 2.2
BuildID: 20150514002501
Gaia: aac58a063e3e6acae6ba77fe4cec224fb69450bc
Gecko: 47f1ced9f1d6
Gonk: ab265fb203390c70b8f2a054f38cf4b2f2dad70a
Version: 37.0 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
----------------------------------

Repro frequency: 5/5
See attached: 
screenshot
logcat
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Summary: [Date&Time] First observancce of 'Time Zone' when 'Date & Time' is set to Automatic may display placeholder: 'America/New_York' → [Date&Time] First observance of 'Time Zone' when 'Date & Time' is set to Automatic displays placeholder: 'America/New_York'
Attached file logcat_20150514_1456.txt (deleted) —
[Blocking Requested - why for this release]:
Placeholder text in a very visible area.
blocking-b2g: --- → 3.0?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Whiteboard: [3.0-Daily-Testing] → [3.0-Daily-Testing][systemsfe]
Whiteboard: [3.0-Daily-Testing][systemsfe] → [3.0-Daily-Testing]
Can't reproduce (my default always shows Asia/Taipei with/without SIM card)

Ask help for reproducible steps.
Keywords: qawanted
I was able to reproduce this bug using the latest Flame 2.5 engineering build.  I used the STR listed in Comment 0.  

Device: Flame 2.5 (KK, Shallow Flash)
BuildID: 20150716121625
Gaia: 77bc0d940bde2a5d2d4dfadfcccc6d8d77456d36
Gecko: 8d262d1d0ae5
Version: 42.0a1 (2.5) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
As comment 3 I can't reproduce it because my default display timezone always shows Asia/Taipei, And FTU does not show the time zone selection as it was. If I change time zone in settings and set to auto again, the timezone shows UTC+8 instead.

If you can provide steps to set default timezone and show the target string, then I can debug it in different time zone, or the issue would left for people in that timezone.
Flags: needinfo?(ddixon)
Fred, 

Sorry for the vagueness of my last comment.  I've discussed this issue with my team, and we recognize the multitude of bugs and/or inconsistencies with the Date/Time behavior.  We are not sure what causes our devices to default to the America/New York time zone (with or w/o our SIM cards).  Also, our SIM cards are from California as well which doesn't make much sense either.  In conclusion, I can't provide you with better STR.  Sorry!
Flags: needinfo?(ddixon)
denominate until got better STR
blocking-b2g: 2.5? → ---
Can we get some help here to get the phone to set to a different timezone initially to help the developer reproduce the bug?
Flags: needinfo?(nhirata.bugzilla)
This is hard coded to US/NY see https://bugzilla.mozilla.org/show_bug.cgi?id=975815.
The timezone doesn't take into account when flashing the device.

The other regression would be https://bugzilla.mozilla.org/show_bug.cgi?id=1172609 which happen just recently.  ( after this bug was reported )

If you can't reproduce this, currently, then I would chalk it up to issues with timezone internationalization or possibly the first bug I mentioned.  We do need a fix for both.
Flags: needinfo?(nhirata.bugzilla) → needinfo?(pcheng)
Fred, please see comment 9. According to Naoki, everyone is defaulted to New York unless you change it during FTU. I suggest you take out your SIM and reflash again. Please let us know if flashing without SIM reproduces the issue.
Flags: needinfo?(pcheng) → needinfo?(gasolin)
Attached image NY.png (deleted) —
After remove the SIM card and reset the device, the `New York` string still looks fine to me.
Flags: needinfo?(gasolin)
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
Fred,

That's not the right environment you're seeing. You have to be in a condition where Time and Date is set to Automatic (it looks like you don't have Automatic because you don't have SIM) AND defaulted to New York.

If you couldn't handle this could you NI someone else who can take a look?

Naoki, could you think of anyone else that can take a look at this?
Status: RESOLVED → REOPENED
Flags: needinfo?(nhirata.bugzilla)
Flags: needinfo?(gasolin)
Resolution: WORKSFORME → ---
Maybe Yura, it's in settings.

Yura, could you take a look please?
Flags: needinfo?(nhirata.bugzilla) → needinfo?(yzenevich)
Thanks. Removing steps-wanted because I believe we've got the steps all along.
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: steps-wanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Since we does not release our devices in New York, we can hold on this issue and focus on what really effect users.
Flags: needinfo?(gasolin)
So it looks like the timezone string is set directly from 'time.timezone' setting when it's set to automatic. If I'm understanding correctly, it's just not localized?
Flags: needinfo?(yzenevich) → needinfo?(pcheng)
It's possible that it's just not localized. Also I found that this issue is not limited to New York, I also saw 'Los Angeles' would display as 'Los_Angeles'. However I tried a few other cities with 2 words but they seem to only display 'UTC-07:00' (example) so I don't know what the rule is here.

STR:
1) Go to Settings > Date & Time
2) Disable 'Set Automatically' if it's enabled, and change City to Los Angeles
3) Enable 'Set Automatically'
4) Back out to previous page in Settings, and enter Date and Time again.

----

NI Delphine to look into this and find out whether this could possibly be a localization issue?
Flags: needinfo?(yzenevich)
Flags: needinfo?(pcheng)
Flags: needinfo?(lebedel.delphine)
(In reply to Pi Wei Cheng [:piwei] from comment #17)
> It's possible that it's just not localized. Also I found that this issue is
> not limited to New York, I also saw 'Los Angeles' would display as
> 'Los_Angeles'. However I tried a few other cities with 2 words but they seem
> to only display 'UTC-07:00' (example) so I don't know what the rule is here.
> 
> STR:
> 1) Go to Settings > Date & Time
> 2) Disable 'Set Automatically' if it's enabled, and change City to Los
> Angeles
> 3) Enable 'Set Automatically'
> 4) Back out to previous page in Settings, and enter Date and Time again.
> 
> ----
> 
> NI Delphine to look into this and find out whether this could possibly be a
> localization issue?

Yes these STI works as well. It looks like we plainly display the setting value, be that the city or the timezone.
Flags: needinfo?(yzenevich)
There's a long outstanding bug about city names being hardcoded both in FTE and Settings: Bug 833393
Otherwise I think Naoki provided good info in comment 9. Not sure if you need anything else, let me know.
Flags: needinfo?(lebedel.delphine)
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: