In the first time user experience, and setting my timezone and wifi, the date defaulted to March 5th, 1970 (noticed once getting SSL errors when opening the Firefox Marketplace). Expected: Date and Time to be set if wifi available, based on timezone, or atleast be close to the actual date to avoid SSL errors (most users won't know about SSL & dates, and instead see startling warnings on HTTPs sites). Actual: Date defaulted to March 5th 1970.

From the TCP program, flatfish, Boot2Gecko 1.4.0.0-prerelease, flatfish_20140120-1529

I don't have a device on me at this moment, but are you given a first time set up menu? If not, that should be worked on.. I'm not sure how we can default on devices right now since the current devices are being shipped to participants of the program but maybe this could be worked on once consumer devices actually launch?

In mine I had the date of 22 May 1970. I received it yesterday (the 22nd), so, if it's not a coincidence (but Jordan opened the bug on 5th and had it defaulted to 5th) I guess it takes correctly only the day. I think it should default to 2014. When upgraded to 2.1.0.0 I remember that at least the year was set correctly (I forgot to write down a note when doing it). Bug 1021870 is somehow related.

In my opinion there shpuld be validation if user set the date during first use because of those serious issues with certs - no Marketplace, no key web access like webmails and etc. 1. If user set wifi then validation if it is possible to synchronize with NTP. 2. If wifi hasn't been configured then if any other date was set than 1970 by him. 3. If 1 and 2 is false then massage for the user that date should be set because of possible issues with access to web sites including no access to Marketplace. In case of failure for scenario 1 and 2 there also should be a message that date must be set correctly because of problems described in message from scenario 3.

Joe, can you provide some insight on if this should be fixed?

redirecting ni request to Jenny

Fernando, I found FTU is able to retrieve timezone from mcc/mnc data once mobile connection available, but there is no something like sync local time with network right? Is there any concern that we didn't use network time to set date/time in FTU?

(In reply to Sherman Chen [:chens] from comment #7) > Fernando, I found FTU is able to retrieve timezone from mcc/mnc data once > mobile connection available, but there is no something like sync local time > with network right? Is there any concern that we didn't use network time to > set date/time in FTU? Yes you're right, only network provided timezone is implemented. As if there was any concern, I can't answer about the time that it was firstly implemented, as I did not take part on that, but I've been checking and apparently we use NTP for the 'findMyDevice' feature, so I don't see any reason at the moment not to implement it for FTU.

Found this highly related bug 904021

Currently, I'm on mountain time. Wifi connected to before moving to next step. Currently this is what is being shown when you visit the screen: America New York 2014-09-02 11:56 AM When you tap the change button, the following occurs: Date: Date auto switches to Sept. 1, 2014 Side note: by changing the city you are in, the display time does not change, however, tapping on the "change" button, the time auto changes. ^A new bug should be opened if not already for the above mentioned.

For some odd reason, the settings I made during set-up did not take effect.

Firefox OS is not being worked on