Should we offer users the ability to choose whether the hardware clock is set to localtime or UTC in the Live bootloader? If the Live media is running on a Windows machine then the hardware clock should be set to localtime, otherwise, if the system is only running Linux then it should be set to UTC.

What should the default be? Maybe the default should be localtime to be compatible with Windows.

If we want to give users the option to select UTC vs. localtime then where should it be located? In the"F4 Options" menu?

Well, I am not sure how many Full Time current Windows users are gravitating toward using AntiX.

Usually the big name releases with gobs of eye candy and Desktop Environment bells and whistles is what
Windows folks thinking of walking on the wild side prefer to try and run.

Not lean and mean.

I don't really care 1 way or the other. The ones that gravitate to us seem to be either computer savvy or
hardware challenged.

As always. I just bow to the majority here.

When conversing with newbies, or potential newbies, I always recommend that they try a 'live' distro first; & I suggest AntiX as a Debian based system. __{{emoticon}}__

(I have no particular preference either way.)

@ BitJam - I say freedom of choice. Use the"option key" F4 to give the user the choice.

@roky - Even win8 users are looking at linux, getting fed up with M$ learning curves and tricks.Many XP users are slowly migrating, but some are finding out how to live with M$ giving up on them. (Note: Getting rid of IE and using Firefox, forgetting about any updates, and using a good antivirus.)

And I agree, most are looking at the pretty distros that remind them of XP or 7. Just think about it. Most users have machines that will run win7. The reason I found antiX was I was fixing a 12 year old machine to run with linux. Now I primarily use a win7 machine with antiX and MX-14, and experiment with different distros.

It's all a matter of Freedom of Choice.

BitJam wrote:Should we offer users the ability to choose whether the hardware clock is set to localtime or UTC in the Live bootloader? If the Live media is running on a Windows machine then the hardware clock should be set to localtime, otherwise, if the system is only running Linux then it should be set to UTC.

What should the default be? Maybe the default should be localtime to be compatible with Windows.

Looking at live use in a wider nomadic manner rather than being limited to the same one or two local machines. In such circumstances it is preferable for antiX to work harmoniously with Windows machines.

The hardware clock can be an obscure concept to a non technical user. The way it is described is important in order to enable the user to select the option that is appropriate to them.

Employing a pseudo"translation" technique is often useful (technical --> translator --> effect). The"translator" might be a question asked by a potential user. Something like What does this mean to me?. It turns"this is what it is" into an outcome or result that has meaning to a non-technical reader. I find it is much more difficult to do than it looks.

BitJam wrote:If we want to give users the option to select UTC vs. localtime then where should it be located? In the"F4 Options" menu?

At the risk of sounding heretical, the forthcoming release presents an opportunity to bring even greater simplicity and coherence to the live boot screen. Each individual boot option might be moved into a single Options menu.

The live boot screen is seen by three principal groups

1. Those evaluating antiX for the first time
2. Those conducting a conventional installation to disk
3. Those choosing to use antiX in live mode

The following are unpolished ideas and wordings.

Reduce number live boot screen F-key menus to three only. Note: F1 help refers to the choices on the main screen not the individual items within the Options menu.

Rationale
To evaluators clarity and ease of understanding are high priorities. Having potentially confusing, inapplicable options displayed on the main screen runs counter to this and is exacerbated by having some options on the main screen and some in a menu. A single location for all is more logical, it is the only location a user has to consider.

Those installing to disk are highly likely to have evaluated antiX. Deciding to install it implies they are confident it works as they want possibly by applying the appropriate boot options.

Live mode users will have previously evaluated antiX. It is highly likely that they will save their boot choices for their specific item of kit i.e. they have created a boot profile. Each time they boot it is this profile they want to automatically use, which means the other options remain unused. A saved profile is less useful used on an unknown item of kit, due to the greater risk of failure (true nomadic v one or two local machines).

The F3 profile might contain two entries:

1. Boot using shipped default profile
2. Boot using the profile I saved previously

When a profile has been created, it will be automatically selected. If selections were made in the Options menu they will be automatically used in conjunction with the shipped default profile.

Should we offer users the ability to choose whether the hardware clock is set to localtime or UTC in the Live bootloader?

Hopefully, mentioning UTC vs localtime in the F1 text (and in the html docs) would be sufficient.
Cramming yet another"option" onto the screen (Sam gave convincing argument for reverting to 800x600 bootscreen) seems impossible.
Maybe you are considering introduction of a"nested menus" approach?

jdmeaux1952 wrote:@ BitJam - I say freedom of choice. Use the"option key" F4 to give the user the choice.

+1. When I first played around with antiX, I didn't quite understand the difference between the choice and opted for UTC. Well, that resulted in an install that was always a number of hours ahead of the actual local time. I have since learned to always select local time.

Someone new to Linux is not going to know what a boot profile is.
Maybe it should be; Settings - Default or Saved.

KrunchTime wrote:+1. When I first played around with antiX, I didn't quite understand the difference between the choice and opted for UTC. Well, that resulted in an install that was always a number of hours ahead of the actual local time. I have since learned to always select local time.

It all depends on if you are dual booting with Windows or not. if you are dual booting then you want to tell Linux the hwclock is set to localtime, otherwise you want to tell Linux the hwclock is set to UTC.

If you select"localtime" instead of"UTC" for the hwclock then you will have to manually account for daylight savings time changes (like the one coming up this weekend in the US), although maybe the ntpd daemon will take care fo this for you. If you have the hwclock set to UTC then Linux will take care of the daylight savings changes for you automatically.

If you dual boot with Windows then Windows will adjust the hwclock to account for daylight savings time changes. OTOH if you told Linux the hwclock is using UTC and you dual boot then the clock will be off by hours either in Windows or in Linux (or both).

IMO it is totally brain-dead (for an OS) to have the hwclock use localtime, especially on a portable device that can easily by transported across timezones. Only do this in Linux if you are dual booting with a brain-dead OS such as Windows. Maybe Windows has finally joined the 20th century and started using the hwclock to store UTC.

Once you have the utc versus localtime issue sorted out and once you have selected your timezone properly then the hwclock should get set at shutdown via the /etc/init.d/hwclock script (on installed systems). You can also set it yourself by first setting the correct time and date (for example, with"date" command on the command line) and then running:

@BitJam -- A lot depends on HOW the machine is being used across timezones. When I was driving trucks, we HAD to post our driving times, breaks, reports, etc. per our HOMEBASE time, regardless what timezone we were in.Our driving reports had to have the address of our HOMEBASE to verify our timezones. I could pick up a load in Miami Florida and end up delivering it to Juneau Alaska or up to Whitehorse. Localtime or Timezone didn't matter.

Just a rant. __{{emoticon}}__

It doesn't matter. It still makes more sense for the hardware clock to be set to UTC. Otherwise either the user or the OS has to keep changing the hwclock to adjust for daylight savings time and possible timezone changes which is just nuts. Of course this can but done but it makes everything more difficult and error-prone. It is is a throwback to simple single-user DOS systems of the 1980s before there was an Internet.

An analogy would be with surveying. Yes, I'm sure it is possible to do surveying with your transit set up on the back of a moving vehicle. You can compensate for the motion but nobody in the right mind would do surveying this way. With timekeeping on computers, the fixed base is UTC, regardless of how the time is shown to the user. Maybe you think I'm saying the computer should *display* UTC instead of local time but that is not what I'm talking about. The hardware clock should be a fixed reference set to UTC even though most people have their computers display local time.

Modern computer systems, especially those connected to the Internet, need to keep track of both UTC and local time. UTC is used by the system internally and to talk to other computers while local time usually what is displayed to the users. It is simpler and more stable to have the hardware clock set to UTC so it doesn't ever have to make large jumps. Then calculate local time from this fixed reference. It is nuts to have a hardware clock set to local time so it has to keep jumping around and then calculate UTC from that."Unix Time" (which is what Linux uses) is the number of seconds that have elapsed since 00:00:00 UTC on Thursday January 1st, 1970. This should be a monotonically increasing number. It is like the heartbeat of a Linux system. If your hwclock is set to local time then the system has to convert from local time in the hwclock to UTC for the system time and then back to local time again for what is displayed to the user. This double conversion process is error-prone especially when the hwclock needs to make big jumps due to daylight savings time and/or changes in timezone. It makes much more sense for the system to simply operate in UTC and then convert UTC to local time for display purposes. The creation time and last modified time on files is simply the Unix time, a count of seconds in UTC. This makes it trivial to compare file dates/times regardless of what is happening with the timezone and daylight savings time. An"ls -l" converts the stored Unix Time to local time for display to the user. Just like it is crazy to set the hwclock to local time, it would be even crazier to set the time stamp in files to local time. It would make comparing file timestamps not just a nightmare but impossible. The system needs to use UTC internally for everything and then convert to local time only for display to the user.