11 Replies Latest reply on May 24, 2015 5:59 PM by databuzz

    Sent Time oddities on FMS13 notifications

    robwoof

      I have a new, soon to be production, FMS13 machine. It is running Windows Server 2012 (not R2, just 2012), and I have updated FMS to 13.0.4.400.

       

      At the moment, it has daily and weekly FMS backup schedules that send me a notification email. The daily schedule is set to run at 7:00pm local (UTC +10:00), and it does. The weekly schedul is set to run at 11:00pm local each Friday, and it does. The schedule sends the email, and my email client receives it soon after. However, the Sent Date/Time for the notification emails are 10 hours later than the actual sent time. That is, last night's email is showing a Sent Date/Time of Today 5:00 am, and the Received Date/Time shows Yesterday 7:00 pm. I have checked email in the evening after 7:00 pm, and the email is present, showing tomorrow's date and 5:00 am as the Sent Date/Time. An SMTP Test email from the server Admin Console shows Sent Today 9:42 pm and Received Today 11:42 am (and it was sent today at 11:42 am).

       

      Note that the server's time zone is correct (UTC + 10:00 Sydney/Melbourne/Canberra), and it is showing the correct local date and time on its screen. The Hourly, Daily and Weekly schedules all happen at the correct local time according to the set schedules. It's only the times shown in the Sent Date/Time of notifications that are out by 10 hours. Notifications from the FMS11 server, sent via the same SMTP server, arrive with correct Sent Date/Time info.

       

      The server was set to the correct Time Zone and its Date and Time wre correct before FMS13 was installed. It has been restarted several times since the installation (notably for the installation of the 13.0.4.400 update), but the mismatch between Sent and Received Date/Times remains.

        • 1. Re: Sent Time oddities on FMS13 notifications
          keywords

          Given that there seems to be a consistent 10 hour difference between sent and received times it seems likely that one or the other is showing UTC and the other is showing local time.

          • 2. Re: Sent Time oddities on FMS13 notifications
            robwoof

            Thanks for your input, keywords.

             

            You're right about the offset magnitude, but wrong about the direction.

             

            My location is UTC +10:00. So at 11:42 AM here, UTC is 1:42 AM, not 9:42 PM as per the example given.

             

            So it appears that something in what FileMaker Server is telling the SMTP server about timezones is incorrect. As a result, something is over-compensating for the timezone correction. It's almost as if the SMTP server thinks it's on UTC, but I have verified that it isn't - it's set in the correct time zone as well.

             

            As I stated above, the FMS11 on Windows Server 2008R2 is giving correct results via the same SMTP server, so it's a bit of a head-scratcher.

             

            Cheers,
            Rob

            • 3. Re: Sent Time oddities on FMS13 notifications
              keywords

              Your clarification does indeed point to the Server being the one in error. I gather both you and the Server are in the same timezone, so Server must be the one that is using UTC. Does it get its time from system settings?

              • 4. Re: Sent Time oddities on FMS13 notifications
                robwoof

                Yes, everything in the FMS13 log is listed at the correct local time. Everything happens at the correct local time - I have verified this by watching the backup directory as an Hourly backup is happening, and viewed the server log immediattely after. So everything scheduled task performed by FMS13 happens at the correct local time, and is logged correctly. It's just the email Sent time that's wrong.

                 

                I might have to have a look at the detailed headers of the emails to see if there's anything there that gives a clue.

                 

                I'm just surprised that no-one else has seen this. Maybe no-one else looks at the Sent time of their notifications, only the Received time...

                • 5. Re: Sent Time oddities on FMS13 notifications
                  robwoof

                  Further info: examining the raw source of notifications from the two FileMaker Servers, there is a clear discrepancy in how they are communicating with the SMTP server.

                   

                  FMS13 Message Source Extract:

                  Received: from FMSERVER ([x.x.x.x]) by moore.local with MailEnable ESMTP; Mon, 29 Sep 2014 16:44:29 +1000

                  Date: Mon, 29 Sep 2014 16:44:29 +0000

                   

                  Note the two different timezone offsets: +1000 on the SMTP server, +0000 from FMS, even though the FMS13's OS is set to +1000.

                   

                  FMS11 Message Source Extract:

                  Received: from MTCFMPRO3 ([x.x.x.y]) by moore.local with MailEnable ESMTP; Mon, 29 Sep 2014 04:01:14 +1000

                  Date: Mon, 29 Sep 2014 04:01:14 +1000

                   

                  Note that in the FMS11 example, its timezone offset matches the OS (Windows Server 2008R2) setting (+1000).

                   

                  Interesting note: a Mac OS X 10.8 FMS13 had the following in its message source:

                  Received: from privatedomain.com ([z.z.z.z])

                            by nskntcmgw06p with BigPond Outbound

                            id wvAQ1o00H0GYhmZ01vAQrF; Mon, 29 Sep 2014 07:10:24 +0000

                  Date: Mon, 29 Sep 2014 17:10:24 +1000

                   

                  In this case, the SMTP server is on UTC (+0000), but FileMaker has used +1000, correct and matching its timezone settings.

                   

                  So it looks like a possible bug in FMS13 for Windows.

                  • 6. Re: Sent Time oddities on FMS13 notifications
                    keywords

                    If it's any help I have tested setting Server to send email notifications when a backup schedule runs. It correctly includes the time signature: 2014-09-29 17:15:03.571 +1000. This is on MacOSX10.9.4 / FMS13. Perhaps you are right about a possible Windows bug.

                    • 7. Re: Sent Time oddities on FMS13 notifications
                      databuzz

                      Hi Rob,

                       

                      There have been a number of reports about this issue since FileMaker Server v13 was released - here's one form the official FMI forum with a a response from FileMaker Inc acknowleding this as an issue:

                       

                      http://forums.filemaker.com/posts/5d153efb20

                       

                      HTH,

                      Andrew

                       

                      FileMaker 13 Certified Developer

                      Databuzz

                      - - - - - - - - - - - - - - - - -

                      Phone: +61 2 9484 6565

                      Mobile: +61 418 468 103

                      Email: andrew@databuzz.com.au

                      http://www.databuzz.com.au

                      • 8. Re: Sent Time oddities on FMS13 notifications
                        robwoof

                        Thanks, Andrew.

                         

                        I searched this forum, but obviously not widely enough.

                        Rob

                        • 9. Re: Sent Time oddities on FMS13 notifications
                          user19752

                          Hmm, this is categorized as 'script' and FMP version is selected as 'FMP13' in fmp_bugs database,

                          but indeed, FMP and script is nothing related.

                          In admin console, set SMTP server and send test mail results same wrong date: header.

                          • 10. Re: Sent Time oddities on FMS13 notifications
                            robwoof

                            As an aside, it appears that this bug is gone in 13.0v9 (I didn't test 13.0v5, so I cannot comment on when the bug was actually fixed).