We're sorry Aspose doesn't work properply without JavaScript enabled.

Free Support Forum - aspose.com

Mail flag property

I am able to set flag property for mail. Assigning the flag start and due date in short date format in local time . Outlook spy is converting that values in UTC and showing one day before date as we are in UTC+5.30 time zone ( dec 27 2018 -5.30 becomes dec 26).

As a result in outlook UI flag start and end date is showing one day previous( ie, in UTC instead of local time)

Can you help me on this ?


Please share your sample code and any sample message files with us for reproducing the problem at our end. We’ll look into it for assisting you further.

Yes , will share ASAP. I think issue is because for these date value Outlook is not allowing to set time ,it is only a date which we can assign. But when we assign in aspose the time us getting set as 12 am and outlook us converting it to UTC and giving previous date.


Your sample data and code will help us understand and investigate the issue further at our end. We’ll be waiting for that.

this is the code we are using to set flag

FollowUpOptions option = new FollowUpOptions( flag start date, Flag Due Date ,ReminderDate);
FollowUpManager.SetOptions(f_mapimessage, option);

In outlook there are 4 properties related to flag date .

  1. StartDate - start date of flag in local time.
  2. Due date - flag end date in locat time.
    3.CommonStart - flag start in UTC
  3. CommonEnd - flag end date in UTC

image.jpg (254.5 KB)

While setting flag using aspose we are givingstart andend date values in local timezone and aspose is converting them into UTC and assigning in all these 4 properties.
Not assigning the local timezone value in 1 and 2 property


I am trying to view the properties in Outlook Spy which you have mentioned in the image. However I am not able to view these specific properties in OutlookSpy. Could you please assist us by providing the complete steps to observe these properties. Also if possible, please send us the message with these flags, which is created using only Outlook. We will compare these properties with the one set by Aspose.Email for our analysis.

Find the attached screenshot for 4 properties related to flag:
1.PNG (57.4 KB)
Start and end date of flag in local time.
Start and end date in UTC( we are from UTC+5.30)

I have also attached the PST sample so that you can verify it at your side.
SysTools_PST_Export.zip (340.8 KB)


Thank you for providing output PST file. Could you please send us complete sample code which contains hard coded date values and other settings, instead of variable names? It shall create PST file at the end as well. This shall be complete code which can be compiled and executed without any change and without missing references.

We regret the the inconvenience caused to you in this regard.

No problem we will share ASAP.

Here is the test application:
OnBehalfOf.zip (53.9 KB)
Attachment.zip (456.4 KB)

Here is the screen shot and PST file created by outlook and Aspose.

  1. test1.pst - PST created by outlook (Screen shot : Flag_outlook.png)
    2.test2.pst - PST created by Aspose ( Screen shot : Flag_Aspose.png)

flag.zip (627.2 KB)


I am afraid that this project does not create PST file similar to the one you have sent in the previous post. Could you please send us the exact project which is used to create this PST file (Using Aspose.Email)? It will help us to observe issue in the actual code and share our feedback.

Also please use latest version of the library (Aspose.Email for .NET 18.4) for testing the scenario as here at Aspose, assistance it provided for latest versions only.

Please check with the test application in my last post.
Create a PST using that and check at your side please…
We are using latest version of aspose 18.4.
Please refer the attachment in my last post.


I have checked the code again in the OnBehalfOf.zip in the post here. If we look at the code, we see the commented code which is of main concern to us. Could you please send us exact code which you used for your testing? Following is the function where code is commented.

private bool SaveMAil()
        // mailmessageObj = new MailMessage();
        mailmessageObj = MailMessage.Load(@"C:\Temp\Attachment.msg", new MsgLoadOptions());
        mailmessageObj.Subject = "Test Mail";
        mailmessageObj.Body = "TEST";
        MailAddress Fromaddress = new Aspose.Email.MailAddress("test@gmail.com", true);
        Fromaddress.DisplayName = "Test";
        mailmessageObj.From = Fromaddress;
        mailmessageObj.To = "test1@gmail.com";
        mapimessageObj = MapiMessage.FromMailMessage(mailmessageObj, MapiConversionOptions.UnicodeFormat);
       // FollowUpOptions option = new FollowUpOptions("Follow up", DateTime.Today, DateTime.Today.AddDays(3), DateTime.Today.AddDays(1));
       // FollowUpManager.SetOptions(mapimessageObj, option);
       // FollowUpManager.SetFlag(mapimessageObj, "Follow up", DateTime.Today, DateTime.Today.AddDays(3));
        mapimessageObj.SetMessageFlags((mapimessageObj.Flags & ~MapiMessageFlags.MSGFLAG_UNSENT));
        return true;

Please check the this test application:
OnBehalfOf.zip (56.4 KB)


Thank you for providing sample code.

This issue is observed and logged under Id:EMAILNET-38993 for further investigation. You will be automatically notified once any update is ready to share.

Thank you.
My superior told to get finish up the things within 3 to 4 days.
At the maximum I can give you the 4 days here.
Please share the updated DLL .
Now using 18.4.


The issue has been logged too early and can’t be investigated and fixed in a rush like this as this can raise other issues in the API. But you can prioritize the processing of this issue by opting for Paid support that is also subject to the complexity involved. We’ll update you here once there is some information or a fix version available in this regard.

Thank you.It is quite difficult for me to convence my superior for paid support.
Let me try once but he will not agree on this.
His point is we already paid for DLL and these are their bugs for which we should not pay. We already paid with cost as well as our time on this.


We understand your concerns, but issues need time to be investigated and fixed properly. In addition, issues are dealt on first come first server basis. We’ll update you here once there is further information available in this regard.

PS: The suggestion for Paid Support was just an option to bring it to your knowledge in case of urgency. We do not force our API users for Paid Support and it is totally up to them to opt for it or not.