When the task is shown on the outlook client, the
data format is not according to my local machine date
time settings. How can this be corrected. See
attachment.
That's strange - it's not the date format that looks like
the problem, but that the date was converted to 0. (This
plugin doesn't do any of that date formatting anyway -
dates are given to Outlook/Exchange as variant date
values). The plugin converts from Remedy's unix time
(epoch time, seconds since 1970) into a variant value of
type VT_DATE, which is a floating point number. I have
not seen any problems with this conversion myself, unless
you synchronize an entry that has a date specified, and
then later on that date field has a NULL value in Remedy
for that entry. Outlook does not provide a way to reset
the date field to NULL via its COM API.
Has anybody else seen problems with date fields not being
converted to Outlook properly?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I also have a date problem. Our Remedy server is in the
Central Time Zone, so all of my Tickets are put into the
calendar one hour earlier. Is there any way I can get the
source so I can add an hour to the time, or can you add
time modifier on the remedy properties form.
By the way this is very cool! I like it alot, even with
the time issue!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm pretty sure the problem with the one hour difference
isn't a timezone problem, but instead a daylight savings
problem. I'd have to look into that. Unfortunately
Outlook uses the OLEDATE variant date format, which is the
worst of all (it itself has no real notion of GMT or
timezone, and it is pretty unclear how you are supposed to
handle daylight savings time). I'm converting it based on
some Win32 methods to get the local timezone config, and I
believe I'm subtracting the standard timezone offset, not
daylight savings.
The source code is all avaliable in CVS, by the way. You
would need VS .NET 2003 to build it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: NO
Neglected to say that I like the tool. If you need to
contact me - basil.webster@siemens.com
Logged In: YES
user_id=1410222
That's strange - it's not the date format that looks like
the problem, but that the date was converted to 0. (This
plugin doesn't do any of that date formatting anyway -
dates are given to Outlook/Exchange as variant date
values). The plugin converts from Remedy's unix time
(epoch time, seconds since 1970) into a variant value of
type VT_DATE, which is a floating point number. I have
not seen any problems with this conversion myself, unless
you synchronize an entry that has a date specified, and
then later on that date field has a NULL value in Remedy
for that entry. Outlook does not provide a way to reset
the date field to NULL via its COM API.
Has anybody else seen problems with date fields not being
converted to Outlook properly?
Logged In: YES
user_id=1449036
I also have a date problem. Our Remedy server is in the
Central Time Zone, so all of my Tickets are put into the
calendar one hour earlier. Is there any way I can get the
source so I can add an hour to the time, or can you add
time modifier on the remedy properties form.
By the way this is very cool! I like it alot, even with
the time issue!
Logged In: YES
user_id=1410222
I'm pretty sure the problem with the one hour difference
isn't a timezone problem, but instead a daylight savings
problem. I'd have to look into that. Unfortunately
Outlook uses the OLEDATE variant date format, which is the
worst of all (it itself has no real notion of GMT or
timezone, and it is pretty unclear how you are supposed to
handle daylight savings time). I'm converting it based on
some Win32 methods to get the local timezone config, and I
believe I'm subtracting the standard timezone offset, not
daylight savings.
The source code is all avaliable in CVS, by the way. You
would need VS .NET 2003 to build it.