No follow-up to the "Configuring the clock" dialog when not accepting the time zone

[bugproxy]

== Comment: #0 - Juergen Lobert <email address hidden> - 2018-03-22 04:43:18 ==
Installation was done from the daily-build s390 ISO images.

Scenario:

1. Answering the inital dialogs asking for the location with "Europe/Berlin"

2. In the further course of the installation the "Configure the clock" dialog appears:

   ???????????????????????????? [!] Configure the clock ???????????????????????
   ? ?
   ? Based on your present physical location, your time zone is Europe/London. ?
   ? ?
   ? If this is not correct, you may select from a full list of time zones instead. ?
   ? ?
   ? Is this time zone correct? ?
   ? ?
   ? <Go Back> <Yes> <No> ?
   ? ?
   ?????????????????????????????????????????????????????????????????????????

   Since the location was previously set to "Europe/Berlin" the shown time zone
   "Europe/London" is not accepted and the dialog is answered with "<no>".

3. Although an upcoming "full list of time zone" is promised, such a list is never displayed
    and the dialog progresses to the configuration of DASD devices.

4. After installation is finished and the new system is started, the date command
    shows the time zone of CET which corresponds to the "Europe/Berlin" setting.

So the behaviour of the "Configure the clock" dialog is not correct.

Probably this issue also applies to previous versions since
I found the same behaviour of the "Configure the clock" dialog when
installing Ubuntu 16.04.2.

Installation logs/information from the /var/log/installer directory are attached.

[bugproxy (bugproxy)]

Default Comment by Bridge

[Dimitri John Ledkov (xnox)]

This appears to come from integration of tzsetup & clock-setup.

First of all, we should be detecting correct timezone, via geoip. Would you be able $ curl http://geoip.ubuntu.com/lookup -> and attach it here? Maybe our database is out of date and needs updating to point at DE.

(note it will contain ip address, and location, if this is sensitive we can set the bug to private first, to ensure it is not widely disclosed).

I will try to reproduce this, by e.g. intentionally answering that I am located in Germany, even though I am in the UK as per geoip.

If this question is unexpected and annoying, you can pressed time/zone key via cmdline to avoid these questions whats-so-ever.

[Frank Heimes (fheimes)]

It's probably similar like you want to try.
In this case geoip response with UK/London (because that's were the intranet/internet passage is), but the system itself is in Germany, hence Europe/Berlin is selected.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2018-08-31 08:48 EDT-------
Set to Prio=low.. circumventiona awailable...

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2019-05-23 03:27 EDT-------
@Canonical. will that be fixed with the new Installer with 19.10 ? Than I will change the target release to 19.10 ???

[Frank Heimes (fheimes)]

Yes, probably.
I am going to leave this ticket open until there is a version of the new installer that can be used to verify this.

[Frank Heimes (fheimes)]

Setting to 'In Progress' with the work on subiquity.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2020-02-11 05:00 EDT-------
@CAN. Will that be fixed with the new subiquity installer?

[Michael Hudson-Doyle (mwhudson)]

subiquity does not currently let you set the timezone at all.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2020-03-04 10:16 EDT-------
@Canonical: Does that mean this request will "WILL NOT BE IMPLEMENTED"
Please provide your input for finalization of the LP......

[Frank Heimes (fheimes)]

Well, not exactly - it first of all means that manual clock and TZ configuration is in the current version of subiquity not addressed by any UI screen. And this will probably not change with the subiquity version that is shipped with 20.04 GA.
In case there are good reasons to have this, a ticket can be opened, this feature requested and the development team will triage and decide...
Please notice that this is the same on all architectures.

[Frank Heimes (fheimes)]

The focus regarding installer moved to subiquity with 20.04.
And since clock and TZ are discovered and/or set automatically this ticket is at least Invalid for the subiquity version that is currently in development for 20.04.
Hence setting this ticket to Invalid.

In case future testing shows that setting clock and TZ post install - usually using timedatectl - is (for whatever reason) not appropriate and there is a need to add it to the installer, I suggest to open a new ticket and explicitly requesting this.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2020-03-23 04:03 EDT-------
IBM Bugzilla status-> closed, Will not be fixed by Canonical

[Dimitri John Ledkov (xnox)]

The new installer is now out.