How to Retrieve Original Sender Timezone and mailbox timezone from Outlook Email via EWS and Aspose.Email

Rollavaipalli Jayanth 0 Reputation points
2025-10-31T04:50:17.0333333+00:00

Forum Question: How to Retrieve Original Sender Timezone from Outlook Email via EWS and Aspose.Email

Problem Statement

I am fetching emails from an Outlook mailbox using Exchange Web Services (EWS) and Aspose.Email for Java. The emails are sent by users from their Outlook desktop application (Windows).

Issue: All timestamp properties and headers are returning UTC time (+0000) instead of the sender's local timezone. I need to identify and persist the original timezone in which the email was sent.


Environment Details

Email Client: Microsoft Outlook Desktop Application (Windows)

Email Server: Microsoft Exchange Online (Office 365)

API Used: Exchange Web Services (EWS)

Library: Aspose.Email for Java

Sender Location: India (IST - UTC+05:30)

Expected Timezone: +0530 (IST)

Actual Timezone in Email: +0000 (UTC)


Methods Tried (All Return UTC)

1. MapiMessage Properties

MapiMessage mapiMessage = client.fetchMessage(messageId);

// All these return UTC time
Date deliveryTime = mapiMessage.getDeliveryTime();
Date clientSubmitTime = mapiMessage.getClientSubmitTime();
Date creationDate = mapiMessage.getCreationDate();

// Tried accessing MAPI properties directly
MapiPropertyCollection properties = mapiMessage.getProperties();

// PR_MESSAGE_DELIVERY_TIME (0x0E060040)
MapiProperty deliveryTimeProp = properties.get_Item(0x0E060040L);
Date time = (Date) deliveryTimeProp.getData(); // Returns: 30-10-2025 22:28:11 (UTC)

// PR_CLIENT_SUBMIT_TIME (0x00390040)
MapiProperty submitTimeProp = properties.get_Item(0x00390040L);

// Checked timezone-related properties (all return null or don't exist)
MapiProperty senderTimeZone = properties.get_Item(0x0E09001FL); // PR_SENDER_TIME_ZONE - NULL
MapiProperty timeZoneDesc = properties.get_Item(0x8234001FL);   // PidLidTimeZoneDescription - NULL
MapiProperty timeZoneStruct = properties.get_Item(0x82330102L); // PidLidTimeZoneStruct - NULL

Result: All properties return UTC time. No timezone-specific properties found.


2. Email Headers (MapiMessage)

// Date header
String dateHeader = mapiMessage.getHeaders().get("Date");
System.out.println(dateHeader);
// Output: Thu, 30 Oct 2025 15:28:10 +0000

Result: Date header shows +0000 (UTC), not sender's timezone.


3. Transport Message Headers

String transportHeaders = mapiMessage.getTransportMessageHeaders();
System.out.println(transportHeaders);

Output:

Received: from <Removed PII>.PROD.OUTLOOK.COM (<Removed PII>) by 
  <Removed PII>.PROD.OUTLOOK.COM with HTTPS; Thu, 30 Oct 2025 15:28:11 +0000
Received: from <Removed PII>.PROD.OUTLOOK.COM (<Removed PII>) by 
  <Removed PII>.PROD.OUTLOOK.COM (<Removed PII>) with Microsoft SMTP Server 
  (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id <Removed PII> 
  Thu, 30 Oct 2025 15:28:10 +0000
Date: Thu, 30 Oct 2025 15:28:10 +0000
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Oct 2025 17:45:45.3263 (UTC)

Result: All Received headers show +0000. Date header shows +0000. Exchange headers show UTC.


4. MailMessage Class

// Convert MapiMessage to MailMessage
MailMessage mailMessage = mapiMessage.toMailMessage(new MailConversionOptions());

// Check Date property
Date date = mailMessage.getDate();
System.out.println(date);
// Output: Thu Oct 30 17:45:45 UTC 2025

// Check Date header
String dateHeader = mailMessage.getHeaders().get_Item("Date");
System.out.println(dateHeader);
// Output: Thu, 30 Oct 2025 17:45:45 +0000

// Check all headers
String[] allKeys = mailMessage.getHeaders().getKeys();
for (String key : allKeys) {
    String value = mailMessage.getHeaders().get_Item(key);
    System.out.println(key + ": " + value);
}

// Check Received headers
String[] receivedHeaders = mailMessage.getHeaders().getValues("Received");
// All show +0000

Result: MailMessage also returns UTC time. No timezone information found.


5. Searching for Timezone Properties

MapiPropertyCollection properties = mapiMessage.getProperties();

// Searched all properties for timezone-related names
for (MapiProperty prop : properties) {
    String name = prop.getName();
    if (name != null && 
        (name.toLowerCase().contains("time") || 
         name.toLowerCase().contains("zone") ||
         name.toLowerCase().contains("tz"))) {
        System.out.println("Property: " + name + ", Value: " + prop.getData());
    }
}

Result: No properties found with 'TIME' or 'ZONE' in the name.


6. Named Properties

MapiNamedPropertyMappingStorage namedProps = mapiMessage.getNamedProperties();
if (namedProps != null) {
    System.out.println("Named properties count: " + namedProps.getCount());
}

Result: No relevant named properties found with timezone information.


7. MAPI Property Tags Checked

// Complete list of property tags checked (all returned null or UTC time)
long[] timezoneTags = {
    0x0E09001FL,  // PR_SENDER_TIME_ZONE (Unicode)
    0x0E09001EL,  // PR_SENDER_TIME_ZONE (String8)
    0x82330102L,  // PidLidTimeZoneStruct (Binary)
    0x8234001FL,  // PidLidTimeZoneDescription (String)
    0x82570102L,  // PidLidAppointmentTimeZoneDefinitionRecur
    0x82580102L,  // PidLidAppointmentTimeZoneDefinitionStartDisplay
    0x82590102L,  // PidLidAppointmentTimeZoneDefinitionEndDisplay
    0x0E060040L,  // PR_MESSAGE_DELIVERY_TIME
    0x00390040L,  // PR_CLIENT_SUBMIT_TIME
    0x30070040L,  // PR_CREATION_TIME
    0x30080040L,  // PR_LAST_MODIFICATION_TIME
    0x3FF10003L,  // PR_MESSAGE_LOCALE_ID
    0x66010003L   // PR_LOCALE_ID
};

for (long tag : timezoneTags) {
    MapiProperty prop = properties.get_Item(tag);
    if (prop != null) {
        System.out.println(String.format("0x%08X: %s", tag, prop.getData()));
    }
}

Result: Only time properties exist (returning UTC). No timezone properties found.


Observations

Email was sent from Outlook Desktop Application by a user in India (IST timezone)

Email server is Exchange Online (Microsoft 365)

All headers show +0000 (UTC timezone)

No MAPI properties contain timezone information

Transport headers from Exchange also show UTC

The email appears to be normalized to UTC before leaving the sender's Outlook client or by Exchange Server


Questions

Is there any way to retrieve the original sender's timezone from emails sent via Outlook Desktop Application?

Does Outlook/Exchange store the sender's timezone anywhere in:

MAPI properties?

  Extended MAPI properties?

  
     Named properties?

     
        Custom X-Headers?

        
           Exchange-specific properties?

           
           **Why is Outlook sending emails with UTC timezone** instead of the sender's local timezone in the Date header?

           
           **Is there a configuration setting** in:

           
              Outlook client?

              
                 Exchange Server?

                 
                    That would preserve the sender's local timezone?

                    
                    **Are there any EWS-specific properties or methods** to retrieve timezone information that we might have missed?

                    
                    **For Aspose.Email users**: Are there any Aspose-specific methods or properties to extract timezone that we haven't tried?
 

Expected Behavior

When a user in India (IST, UTC+05:30) sends an email at 8:58 PM local time:

Expected Date header: Thu, 30 Oct 2025 20:58:00 +0530

Actual Date header: Thu, 30 Oct 2025 15:28:10 +0000

The timezone information (+0530) is being lost somewhere in the process.


Request for Help

Is there any official way to retrieve sender's timezone from Outlook emails via EWS/MAPI?

Are we missing any properties, headers, or methods in our investigation?

Is this a known limitation of Outlook/Exchange?

What is the recommended approach by Microsoft/Aspose to handle this scenario?

Any guidance would be greatly appreciated!


Additional Information

This is for a business application that processes emails programmatically

We need to display email timestamps in the sender's original timezone

We have tried both Aspose.Email's MapiMessage and MailMessage classes

All debugging output is from actual production emails

Users are sending emails from properly configured Outlook clients with correct timezone settings

Thank you for your help!

Exchange | Exchange Server | Development
0 comments No comments
{count} votes

1 answer

Sort by: Most helpful
  1. Hin-V 10,180 Reputation points Microsoft External Staff Moderator
    2025-10-31T07:50:02.3833333+00:00

    Hi @Rollavaipalli Jayanth

    Thank you for posting your question in Microsoft Q&A.

    Please note that our forum is a public platform, and we will modify your question to hide your personal information in the description. Kindly ensure that you hide any personal or organizational information the next time you post an error or other details to protect personal data.  

    As my research, this could be a standard behavior in how Microsoft Outlook and Exchange handle email timestamps, particularly the normalization to UTC,is a standard and intentional design choice. 

    UTC as the Standard: Outlook and Exchange use Coordinated Universal Time (UTC) as the internal standard for storing and processing all timestamps. This ensures consistency across global systems and avoids issues related to daylight saving time (DST) or cross-timezone discrepancies. 

    Timestamp Normalization: When an email is sent from the Outlook desktop client (via HTTPS/MAPI to Exchange), the Exchange server normalizes the "Date" header and other timestamp properties to UTC. This normalization happens during submission and is part of Exchange Online’s infrastructure behavior. 

    Local Time Not Preserved in Transport: The sender’s local time (e.g., IST +05:30) is used only for display purposes on the sender’s device. It is not embedded in the email envelope or standard headers. Instead, all transport headers (such as Received lines, X-MS-Exchange-CrossTenant-OriginalArrivalTime) are stamped in UTC. 

    This normalization is performed by Exchange, not the Outlook client. It typically occurs during the initial "Received" hop within the sender’s Exchange tenant, before the email is transmitted externally. 

    References: 

    How time zone normalization works | Microsoft Learn 
    exchangewebservices - How to determine (through EWS) what time zone Exchange Server uses? - Stack O… 

    Currently, I have not found a reliable method to retrieve the original sender's timezone. Unfortunately, when a message is sent via Outlook Desktop to Exchange Online, the sender’s timezone is not stored or preserved in the message properties, headers, or metadata. 

    Regarding Aspose.Email-specific methods, I am unable to provide guidance as my focus is strictly on Microsoft technologies. As a forum moderator, my role is to support Microsoft-related inquiries, and I don’t have access to backend systems or resources to investigate third-party implementations. 

    This summary is based on my findings from the community and several relevant threads. To investigate this further, I recommend posting a thread on the Microsoft Tech Community forum. It’s a great platform for deeper technical discussions and connecting with individuals who have hands-on experience and expertise. They’re best positioned to provide guidance and valuable insights on this topic.    

    Apologies for redirecting you to the related development team support as the moderators in this community have limited resources to check the backend information, and to get the fast and better assistance we requested for it.   

    If you have any additional concerns, feel free to comment below. I would be more than happy to assist. 


    If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".      

    Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread. 


Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.