Opened 16 years ago

Closed 13 years ago

#1310 closed enhancement (fixed)

Support running systems with "hardware" clock on UTC => Fixed in SVN

Reported by: Frans Pop Owned by:
Component: other Version: VirtualBox 2.0.2
Keywords: Cc:
Guest type: Linux Host type: other


As you probably know, linux mostly runs on systems with the hardware clock set to UTC; the timezone setting will correct that time to the correct local time.

VirtualBox currently always takes the local time of the host system as its hardware clock, which means that when I use VirtualBox for my Debian linux installation tests, I always end up with the clock set wrong as the Debian installer sets the system clock to UTC during the installation if no other operating systems such as Windows are detected. However, when the virtual machine is restarted, it gets set back to local time.

It would be great to have a per-machine config setting that lets the user choose between having the "hardware" clock of the virtual system in local time or in UTC (based on the host system's local time + its timezone setting).

TIA, Frans Pop

Change History (16)

comment:1 by Hilco Wijbenga, 15 years ago

I ran into this too. It's *extremely* annoying.

This should be very easy to fix as the type of OS is indicated when creating a new VM. For UNIX-like VMs use UTC, for Windows-* VMs use local time. A tiny little if statement? :-)

(A per-VM config setting would work too, of course. In fact, we should probably have both.)

comment:2 by Frank Mehnert, 15 years ago

Guest type: otherLinux
Version: VirtualBox 1.5.6VirtualBox 2.0.2

I agree, there should be some configuration item in the VM settings which defines if the RTC clock ticks in UTC or local time.

comment:3 by felipe alvarez, 15 years ago

Still happens in 2.0.4 OSE. Installation of opensuse 11.1 (GUEST) on opensuse 11.0 (HOST). HOST runs in UTC, if UTC is selected for GUEST, time is incorrect. If NOT selected for UTC, time IS correct.

comment:4 by josir, 15 years ago

It happens to me either Ubuntu Host and Windows XP SP3 Guest. Is there any workaround for this ?

comment:5 by MarlonNelson, 15 years ago

I ran into this problem running a Gentoo VM.

I found this:

Changing the CLOCK variable from "UTC" to "local" fixed the problem for me.

On my native Ubuntu box, I can see the same /etc/conf.d/clock file with CLOCK="UTC", so I suspect it would work for an Ubuntu VM, also.

comment:6 by David Whitmarsh, 15 years ago

This is frustrating for me as well. Especially since it has been opened for a year.

I'm not posting this for Frans since he is very familiar with Debian and the Debian Installer. Instead I'll post it for people like me who found this page while googleing for a solution.

You can teach Debian that the hardware clock is not UTC but is instead local time by setting 'UTC=no' in the file '/etc/defaults/rcS'. You can also boot Debian Installer with d-i:clock-setup/utc=false in the kernel arguments to tell the installer not to put UTC into the hardware clock

comment:7 by Paul Bransford, 14 years ago

I agree. This should be a user configurable option on a per-VM basis, or at the least a system-wide setting in vbox's configuration.

comment:8 by mh, 14 years ago

The "correct" time is UTC, period. Letting local time mess with system internals is a nightmarish source of numerous problems listed here:

Think for instance:

  • What if you boot your VM in a different timezone than usual? Then the VM's clock is completely screwed up (changing the Unix "TZ" variable is enough to reproduce this bug). Simply providing the virtualized hardware clock in UTC solves this problem.
  • What if your VM boots right at the end of the daylight saving period, when one hour of local time is REPEATED!? Which "2:35 AM" should the operating system pick, the first or the second one?

Local time is a pure user-friendliness issue. It must be strictly restricted to user interfaces and never bug system internals.

comment:9 by Frank Mehnert, 14 years ago

Please could you calm down? Ranting will not speed up things.

comment:10 by mh, 14 years ago

Sorry about the incisive tone; it was not directed at the developers at all. It was directed at people confused by this problem (as I was) and googling for a solution: whenever you hear or read that this UTC/local time debate is complicated, ignore it.

The only case where things become complicated is when you are unfortunately forced to follow the Microsoft tradition (= local time in the hardware clock). Once you can get rid of local time everywhere but in the user-interface, all problems and bugs are gone.

comment:11 by Frank Mehnert, 14 years ago

Btw, setting

VBoxManage setextradata VM_NAME "VBoxInternal/Devices/mc146818/0/Config/UseUTC" 1

should already work.

in reply to:  11 comment:12 by Frans Pop, 14 years ago

Replying to frank:

Btw, setting

VBoxManage setextradata VM_NAME "VBoxInternal/Devices/mc146818/0/Config/UseUTC" 1

should already work.

Thanks. In which version was this implemented?

Also, it's nice to have the option, but that's not really a user friendly and visible method to select such an important option.

Cheers, FJP

comment:13 by Frank Mehnert, 14 years ago

VirtualBox 3.1.0 is the first release which supports this setting.

comment:14 by Frank Mehnert, 14 years ago

Summary: Support running systems with "hardware" clock on UTCSupport running systems with "hardware" clock on UTC => Fixed in SVN

GUI support for this setting was recently added, the setting will be available in the next major release.

in reply to:  14 comment:15 by Frans Pop, 14 years ago

Replying to frank:

GUI support for this setting was recently added, the setting will be available in the next major release.

Excellent! Thanks a lot.

comment:16 by Frank Mehnert, 13 years ago

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.

© 2023 Oracle
ContactPrivacy policyTerms of Use