Parallels 5 and DST structure

Using XP in Parallels 5 on Snow Leopard, the structure returned giving the DST information seems to be bad. We have an application that depends on this data and it is reporting that that data is not properly formatted. I do not know the API being called right now but will post it next week when I can get to the code. I have reverted to Parallels 4 and the problem goes away, so it is definitely a Parallels 5 issue. Is this a known issue and is a fix in the works?

 

Continuation of the DST issue

The following windows code is used to get the DST info:

TIME_ZONE_INFORMATION timeWarp;

DWORD tz_result = GetTimeZoneInformation(&timeWarp);

Our code splits this structure and sends the fields individually. The other side of this transaction reports

Month = 0
Day = 1
seconds = 7200

as not being valid for DST info

 

Will there be a resolution to this issue

I've been troubleshooting everything from the wrong end. Three machines running snow leopard and upgraded to parallels 5 from 4. All have XP Professional loaded with MS Office 2007. Appointments sent out to attendees show one hour off in the DST calendar dates and in user's Blackberry. I went route of troubleshooting the XP OS, Outlook, BES Server and Exchange Server and nothing worked. Then I found this article, which is promising, but is there something that is going to change with 5.

 

more information

When checking against OWA, it shows one hour off in the DST time affected dates compared to the Outlooks running in the Parallels environment.

Also set up another desktop on Windows Vista running 2007, shows one hour off from the calendar in the DST affected dates compared to the Parallels environment running Outlook 2007.

The time shows correctly on the XP OS of the Parallels 5.0 environment.

 

Build 9308 Does not help

I loaded Build 9308 today and am getting the same failure as described above.

 

Hi,

Could you do the following:

1. Open VM configuration and check if "Allow different time than in Mac" option is OFF in the Option -> Services tab
2. Close VM configuration
3. Open Date and Time in Windows XP and set "Automatically adjust clock for daylight savings change" to checked
4. Close Date and Time window
5. Wait about a minute and check.

Alexander

 

Answer to Alexq

1. Already Off
2. NA
3. Already Checked
4. NA
5. Since there were no changes this is NA.

Looks like all was already set as desired.

Still getting error
Daylight savings time start values of month 0, week 2, day 1, and second 7200 are not valid.
The values come through as follows:

From a XP Pro on raw hardware:
Start Month: 3
Start Week: 2
Start Day: 1
Start Seconds: 7200
End Month: 11
End Week: 1
End Day:1
End Seconds: 7200

Exact same code running on XP Home on top of Parallels 5 build 5.0.9308 Revision 543312

Start Month: 0
Start Week 2
Start Day: 1
Start Second: 7200

End Month: 11
End Week: 1
End Day: 1
End Second: 7200

Looks like the Start Month is coming back wrong from the Windows Call

Good XP also has Automatically adjust clock for daylight saving changes checked.

Cannot check on Parallels 4 right now. But I would expect the same result as for raw hardware XP Pro. My Parallels 4 system is also running on Snow Leopard with XP Home.

 

What I found is that on the Windows XP side, the time zone changed from (in my case) Eastern Time (US & Canada) to Bogata, Lima, Quito. It will not keep my default time zone and will switch automatically. It is consistent on both my MacBook Pro and iMac. I am running Leopard 10.6.2 on the Mac side and Windows XP Pro SP3 on the Windows side on both. The problem started when I upgraded to Parallels 5.

 

Hello EZED50,
do you have still the bug (with Bogata,...)? Could you make the following: open Terminal (press Shift+Command+U and run "Terminal"), type 'date' command there and press Enter. Print its output here. (It must be smth like 'Mon Jan 11 13:59:05 MSK 2010')

 

Latest Parallels 5 update does not help

I have installed today's update Build 5.0.9310 Revision 546799 and get the same behavior as already reported.

 

I'm having the same problem. Parallels is set to sync time with the Windows XP guest and it keeps setting the time zone to (GMT-05:00) Bogota, Lima, Quito, instead of Eastern Time. The workaround is to suppress the time sync, but is there a permanent fix?

 

Hi milleri,
permanent fix should be available in next update of Parallels Desktop 5.

 

Very good. I know you don't comment on release timing, but this bug is very disruptive so sooner is better than later. Thanks! imm

 

Good to hear. Can you give an estimate of when the next patch will be released?

 

Setting the time to "Synchronize with Mac" and enabling "Allow a different time than on Mac" is an acceptable workaround. It keeps the time synced but doesn't change the time zone.

 

Bogota time zone on one VM but not the other

I'm getting a similar problem but only in this one VM. My WinXP virtual machine does this same thing. My Windows 7 vm does not. My VMware WinXP vmachine does not do this either.

I only raise this in case it helps with figuring out what the problem is.

Looking forward to the patch - this is a pain.

 

Please click one of the Quick Reply icons in the posts above to activate Quick Reply.

 

Build 5.0.9344 just out seems to solve my problem.

 

Timezone fix works, but now Outlook can't open archived PST files

Parallels... thanks for the latest update, it seems to have fixed the timezone issue, which was quite annoying. This has also corrected the Outlook calendar's ability to view availability of other invitees. Thanks!

But since applying the update, Outlook isn't able to access any of my archived emails, which are stored across multiple PST files on my local drive and on our network. I never had a problem previously, only after applying the latest Parallels Desktop 5 patch. Our office Tech worked on it yesterday but couldn't figure out the problem. He verified that my PST files are not corrupt, after running scanpst and since he was able to open them without any problems using another PC on the network and also through our remote apps system. He theorizes that the problem is somehow associated with file associations within Parallels.

Do you have a fix for this? Please help! Thanks.

 

Hi,
In order to understand the situation: are you accessing these files using SMB-share (network) or using SharedFolders? Does accessing using SMB-share (when SharedFolders are not involved) works?