Setting guest date persistently + accurately relative 2 host

[Don't nick my name]

I am running an XP (32 bit) guest on a Windows 8.1 (64 bit) host and would like the guest date to be 10 years less than the host's. The following command works once but I have to re-execute it each boot then change the guest time manually.

Code: Select all

vboxmanage setextradata "vmname"  “VBoxInternal/Devices/VMMDev/0/Config/GetHostTimeDisabled” “1″

Another (better) approach is

Code: Select all

VBoxManage modifyvm "vmname" --biossystemtimeoffset  -315600000000

So I make this a scheduled task that executes at boot time (of the real PC) and yea the date is about 10 years less than current.

But why 'about' ? It seems that there is some rounding going on as I seem to be always 18 hours 50 minutes less than 10 years. I thought this may be taking leap years into account so I changed the millisecond figure to 315569520000 there being 365.2425 days in a year. That seemed to have no effect so I 'manually' added back 18:50 worth of milliseconds which yields 309086520000 but still the time remains 10 years 18 hours and 50 minutes less than the current ! If you have time to do so, please explain.

[loukingjr]

Depends on what you count as a year.
10 sidereal years = 3652.563604167 days or 3.155814954e+11 ms.

[Don't nick my name]

No it depends on what VirtualBox calculates the number of milliseconds to be. I just plugged in your figure of 315581495400 and the time is still 18hrs 50min behind reality - 10 years.

[loukingjr]

Seeing your guest is XP 32bit and only has 32bit registers I would think the rounding error occurs there. I could be wrong.

[Don't nick my name]

I think that's probably it. We need 39 bits to express that number in pure binary.

[loukingjr]

I think so also. You could try with a 64bit guest or use a much smaller offset and see if it's accurate.

[mpack]

Sorry guys, not true. Whether VirtualBox allows a 64bit time offset I don't know, but the nature of the host OS doesn't affect whether it can do that calculation or not (or store quantities of that size).

The host CPU (never the OS) only affects how quickly the calculation can be done. If that wasn't the case then 32bit OS's would be limited to 4GB files, since it couldn't represent larger numbers, right? Obviously that isn't the case.

In fact it is quite easy to do 64bit arithmetic on a 32bit machine. Even easier if you have a 64bit CPU (which they almost all are, and have been for maybe five years now).

The thing that sets a 64bit OS apart is that it can do linear addressing (as opposed to segment:offset) on blocks of RAM larger than 4GB. So, address pointers are >32bits, and linear. There may be a small performance penalty for this, since copying memory pointers around now requires twice as much bandwidth as before. That's the only difference. Hence my frequent puzzlement that people will install a 64bit OS on hosts that have <4GB RAM installed! They can't access more memory, but they still get that small penalty. I can see doing that if the intention is to upgrade the host RAM, or test a specific 64bit-only app.

[loukingjr]

Don, I don't hink the question was whether a 32bit machine can do 64bit arithmetic. An 8bit computer can do 64bit arethmetic and more. I had a program running on a Commodore 64 which could arithmetic on arbitrarily large integers such as one 128 digit number times a 256 digit number and print out the exact result. The only limitation was how long one was willing to wait to print out the results.

My thinking was whether or not the developers of XP saw any reason to store and work with large date offsets. It seems to me we had the whole Y2K Millennium Doomsday predictions because of it. I could be remembering it incorrectly. At any rate as I mentioned it would be easy enough to check on Windows XP 32bit by using a much smaller time offset something under 32bits in length.

[Don't nick my name]

In which case the original question still stands as a mystery. I wonder if it could be a bug in VB.

[mpack]

Well, you both seemed to be heading towards a consensus that trying a 64bit host OS might have an affect, whereas my point is that the host OS doesn't dictate what type of arithmetic an app can do. Instead its the library the app links against which dicates that - and every modern language runtime lib supports 64bit int types and 64bit arithmetic.

I'd say: it's possible this parameter is limited to 32bits on both 32bit and 64bit hosts. It's also possible that it's 64bits on both types of hosts, but I very much doubt that it changes with the host.

[loukingjr]

Well, when I mentioned a 64bit guest I was actually thinking of a Windows guest and was only surmising there may have been a change in how dates were handled. Personally I don't need a guest to run 10 years behind the host.

edit: btw, the only reason I questioned the 32bit vs 64bit issue was because despite the OP plugging in 4 different values his results were always 18 hours 50 mins off. That led me to think it was not actually using the value that was being plugged in but a maximum value that could be represented.

re-edit: My last thought on this. If you have a mathematical expression such as…
7 + x = 10
and despite setting x to 4 different values it still results in 10. Either x isn't stored correctly, the expression isn't being solved correctly, or the result isn't being stored correctly.

[loukingjr]

FWIW, I should remember to check the validity of users statements.
When I ran the command from the first post…

Code: Select all

VBoxManage modifyvm "vmname" --biossystemtimeoffset  -315600000000

The time difference I got was 18hrs 40mins 0seconds
When I ran the offset I posted...

Code: Select all

VBoxManage modifyvm "vmname" --biossystemtimeoffset  -315581495400

I got a time difference of 13hrs 32mins 0seconds
Unlike what the OP said he got.

I still don't know what the time offset needs to be but had the OP not said he got the same time difference with both offsets I would not have continued to reply.

[bird]

I've tried this with current VBox trunk code and it works fine, provided the time offset is correctly calculated. Being on a system with bash, the following does the job:

Code: Select all

./out/linux.amd64/debug/bin/VBoxManage modifyvm "linux3" --biossystemtimeoffset -$(( (10 * 365 + 2) * 24 * 3600 ))000

10 year of 365 day plus two lead days (2008 and 2012). (24 hours per day, 3600 seconds per hour, trailing 000 is for milliseconds conversion.) Result: -315532800000

Kind regards,
bird.

[loukingjr]

that is the correct offset. good job bird.

It's good to see at least one of us was thinking.