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