Time problem

[Donald Allen <donaldcallen@xxxxxxxxx>]

I've installed Dragonfly 3.0.2 on an x86_64 box side-by-side with Arch
Linux. Arch is set up for UTC time, America/New_York timezone. When I
installed Dragonfly, I selected 'Yes' in response to the question "Is
this machine's CMOS clock set to UTC?". Nonetheless, when Dragonfly
came up, the time was 4 hours later than it should have been. After a
bunch of detective work, I found that the presence of the file
/etc/wall_cmos_clock indicates that the hardware clock is set to local
time and that it was present. I removed it and the time became correct
after a reboot.

I installed Dragonfly on another system, also x86_64, and this time
Dragonfly is the only system installed. I again answered 'Yes' to the
UTC question and again got the time displayed as 4 hours later than
correct.

I downloaded the sources and had a look at the installer.  This
procedure seems to ask the timezone question:
fn_set_timezone(struct i_fn_args *a)
{
	struct commands *cmds;
	char *s = NULL;
	char current_path[256], selection[256], temp[256];
	int found_file = 0;

	cmds = commands_new();

        switch (dfui_be_present_dialog(a->c, _("Local or UTC
(Greenwich Mean Time) clock"),
	    _("Yes|No"),
            _("Is this machine's CMOS clock set to UTC?\n\n"
	    "If it is set to local time, or you don't know, please choose NO
here!"))) {
		case 1:
			cmds = commands_new();
			command_add(cmds, "%s%s %s%setc/wall_cmos_clock",
			    a->os_root, cmd_name(a, "TOUCH"),
			    a->os_root, a->cfg_root);
			commands_execute(a, cmds);
	}

	snprintf(current_path, 256, "%s%susr/share/zoneinfo",
	    a->os_root, a->cfg_root);
etc. ......

The comment preceding dfui_be_present_dialog says:

/*
 * Create and present a generic `dialog box'-type form for the user
 * and return their response.  actions is a pipe-seperated list of
 * actions to be put on the form (e.g. "OK|Cancel".)  The return
 * value is the ordinal position of the action that was selected,
 * starting at 1 for the first action.  A return value of 0 indicates
 * that an error occurred.  A return value of -1 indicates that the
 * front end aborted the communications.
 */

Minor nit: it's "separated", not "seperated". That aside, this comment
tells me that the call to this function from fn_set_timezone will
return 1 for "Yes", 2 for "No". But fn_set_timezone is creating
(touching) /etc/wall_cmos_clock when 1 is returned. I think the sense
of the switch is wrong. In other words, it should be 'case 2:', not
'case 1:'.

Further searching turns up a bug report about this, Bug #2060. This
bug was entered a year ago. 3.0.2 was released last month and this
hasn't been fixed? It wasted a whole lot of my time and will confuse
hell out of anyone trying to use this system. While perhaps not a
critical bug, in the sense of data loss, it's a serious problem, and
having a bug like this remain unfixed for such a long time really
gives me second thoughts about using this system for anything serious.
It makes me wonder what else hasn't gotten fixed. I'm sorry to be so
blunt, but I'm trying to be constructive. A lot of work has obviously
gone into this system, and to shake peoples' confidence in it by not
attending to something this simple doesn't make sense to me.

/Don