We are running Navision 3.70 and using Citrix XPa SP3/FR3 servers. We are also running Outlook XP on the same Citrix Servers. We have implemented Outlook Integration in Navision. We can set appointments for salesman and it automatically flows to their Outlook. Cool stuff. We have a small problem though. The database is in the Central time zone and we have MANY users in the Eastern time zone (+1 Hour). So if someone in the East Coast schedules an appoinment for a salesman at 11:00 am in the morning in Attain 3.70, it flows to their Outlook and shows up as a 12:00 appoinment. The salesman then shows up an hour late to the appoinment. That seems to be a problem that we should be able to solve. Database in Central Timezone, Outlook set to the timezone of the user, which in many cases is Easter Time zone. Any ideas?
The Datetime Navision data type might help - it is a UTC time when stored in the database. Although it is converted to local time for use in Navision itself, it could be passed on to Outlook as UTC depending on your integration. It would then be timezone independent for your Outlook users, which is of course the point of UTC times.
Robert, Can you pass a little more details on this?
For example, if you enter 1-Jan-2004 12:00 midday local time (i.e. the time as far as you’re concerned) in a Datetime field in Navision, and your timezone is CET (which is UTC+1) Navision will convert it to UTC immediately (using win32 functions - the same used for doing this job with file timestamps which are also stored UTC) and store it in the database. This gives 11:00 UTC. If someone else opened this database and read the value, and their timezone was North America EST (UTC-5) they would not see 12:00 midday but the absolute point in time corresponding to 12:00 CET, which would then be 06:00 EST. So the Datetime represent the absolute times (ignoring Relativity) viewed consistently by all timezones. This is what ‘pszoke’ wants. The problem is that at every entry point into Navision the UTC is always converted to/from local time - you never see the UTC. This is in the UI, dataports and C/AL. I think that automation leaves the UTC value alone so if this is the integration used it should be possible to hand over the raw UTC value to Outlook. But I haven’t been able to try this - holidays for me 
So what you’re saying is that Datetime works different from the “old” TIME variable? Our problem is actually not syncronization with Outlook but global calculation of delivery times, i.e. all orders that are entered before 2pm CET are to be shipped the same day in Europe.
Yes, the Time type is not UTC based and doesn’t respect time zones so a value entered into the system will remain the exact same local-time value everywhere. There is no absolute value stored. In your example you would need to store 2pm CET in a table and compare order entry date-times with it. That would not work with regular Time values because they would all be local times and the comparison cannot be absolute.
This is really great! I just made a small test program to test it and I love it! I vote for converting all times to UTC - but by option in the field!