Inconsistent date/time stamps, *possibly* due to time zone

I have the following functions and constants within (say) FOO.m to generate date/time stamps for *.mat dump file names and diagnostic messages:

% Fine grain date/time
FineDT = @() string(datetime,"yyyyMMdd.HHmmssSS");

% Coarser date/time, but human readable
NiceDTspc = @() string(datetime,"eee yyyy-MM-dd HH:mm:ss ");

% The m-file function  name (say) FOO
mfn = string(mfilename);

My FOO.m m-file function uses the above to dump the workspace to a file:

% Build file name with date/time suffix
MatFN = mfn + "b4ilp" + FineDT() + ".mat";

save(MatFN);

disp( NiceDTspc() + mfn + ... Message prefix: Time & name of m-file
      " : Saved " + MatFN + ".  Calling intlinprog...");

The date/time suffix in the filename is 5 hours later than actual time of the file as revealed by the operating system (OS):

2023-12-22 19:37 FOOb4ilp20231223.00373136.mat
2023-12-22 19:37 FOOb4ilp20231223.00373172.mat

I thought that the OS's date/time might simply be 5 hours ahead because my time zone is GMT - 5 hours. The "disp" command above also issues messages with a date/time prefix that is 5 hours later:

Sat 2023-12-23 00:37:32 FOO : Saved FOOb4ilp20231223.00373172.mat.  Calling intlinprog...
Sat 2023-12-23 00:37:33 FOO : Saved FOOb4ilp20231223.00373136.mat.  Calling intlinprog...

However, when I define the above anonymous date/time functions FineDT and NiceDTspc at the command line, then invoke them, they return the correct local time.

Why would string(datetime,....) above yield the correct local time at the command line, but not from within an m-file function?

I am using Matlab 2023a on Windows 10.

[James Tursa]

Please post a small, complete example that reproduces the problem on your machine, isolating only the datetime issue. Also show us how you are getting the OS file time stamp.

[FM]

I'll respond to this in a comment to Star Strider's answer. Thanks.

Answer 1

[Star Strider]

I can’t determine what the exact problem is (I don’t have access to your computer, and I am not certain that I completely understand the problem), however in the function or script, it could be possible that the time zone is somehow set incorrectly to UCT. Use the datetime TimeZone property to set it correctly in the datetime calls, and if necessary consult the timezones function for a list of them.

[FM]

Thanks, Star Strider. I thought a bit more about how the m-file could impose a different time zone than the command line. There is no code that modifies the time zone.

Then it occurred to me that I wasn't really testing the m-file. I was invoking the m-file after it was compiled into a Java package. It is running off of the Matlab Runtime. There could be differences from the use of "datetime" from the command line (even though the aim is to make them the same).

This turned out to be true. Here are the results from the code in the m-file, but after it is compiled into a Java package and invoked from a Java program:

datetime                         % 24-Dec-2023 05:47:39
datetime('now')                  % 24-Dec-2023 05:47:39
datetime('now',TimeZone='local') % 24-Dec-2023 00:47:39

Only the last of the three calls matches the "correct" time on my laptop clock. So I have to explcitly specify that a local time zone should be used. This contrasts with the behaviour at the Matlab command line, where all 3 invocations yield date/times that match my laptop clock.

My Java code doesn't mess with the time zone at all. I presume that the discrepancy is just an oversight in implementing the Matlab Runtime. But I could easily be wrong, since most of my experience is not with deployment and other languages.

[Star Strider]

As always, my pleasure!

I don’t have the MATLAB Compiler, so I have no experience with it, or Java. I’m happy to have pointed you toward a solution!

If this is a problem with MATLAB Runtime, it could be worthwhile to submit this as a Bug Report if you believe it is a bug. If so, include the URL of this thread is your note to MathWorks so you won’t have to repeat everything here.

[FM]

I went through the bug reporting process, but it resulted in a service request. I didn't really expect servicing, as it was more of my service to TMW to improve subsequent versions of Compiler SDK and/or Matlab. In fact, since this is seen in 2023a (which is what my license is for) and they are already into 2023b, it doesn't make sense for TMW to "service" this. In any case, here is the text of the resulting Case Number 06693941:

Bug report: datetime discrepancy between Matlab & Java pkg

I have the following three statements in an m-file function:

datetime
datetime('now')
datetime('now',TimeZone='local')

When I invoke the function from the Matlab command line, they all yield identical results and all match the date/time shown in Windows 10's system tray area: 24-Dec-2023 00:47:39.

On the other hand, if I compile the m-file into a Java package and invoke it from Java, I get different results:

datetime                         % 24-Dec-2023 05:47:39
datetime('now')                  % 24-Dec-2023 05:47:39
datetime('now',TimeZone='local') % 24-Dec-2023 00:47:39

Only the last statement matches the Windows date/time. The 1st two are 5 hours in advance. Since my time zone is GMT - 5 hours, it is obvious that the 1st two are using UTC time.

The invoking java code is builds upon code that is generated by Compiler SDK from a simple example m-file driver. Nothing I've added sets the time zone, and the Java code is invoked from a Cygwin Bash shell, where the "date" command yields proper local date/time. The only modules imported are:

java.lang.Math
java.io.*
java.util.ArrayList
java.util.Arrays
java.util.List
java.util.Scanner
com.mathworks.toolbox.javabuilder.*
JavaILP.JavaILPclass

Since the compiled Java package uses the Matlab Runtime for Matlab functions, the discrepancy can be summarized as follows: The default time zone used by "datetime" is "local" when using Matlab, but it is "UTC" using the Matlab Runtime.

[Paul]

I'm pretty sure that a service request is generated for any contact with Tech Support, whether for a bug report or anything else, so your experience sounds normal. Have you heard back from Tech Support yet? Usually they respond within a few business days; don't know if that changes around the end-of-year holidays.

[FM]

Yes, they provided a streamlined test case which doesn't exhibit the problem. I've narrowed cause down to the shell from which Java is invoked, so it does not appear to be a Compiler SDK problem. I sent all troubleshooting files to TMW and asked them to close the ticket (but got notified that it was closed before I sent the request). I also posted on Stack Overflow to ask about possible causes for different default time zones pertaining to the invoking shell rather than the JDK or Windows settings.

Update 2024-01-01: The above Stack Overflow posting reports that the default timezone seems to depend on whether I compile and run the Java program from a CMD shell or a Cygwin Bash shell. The Java program is the one that invokes the deployed Matlab function prepared by Compiler SDK. I modified the Java code to show that the default time zone is the same regardless of whether it was invoked from CMD or Bash. Therefore, the Matlab Runtime component seems to be responsible for the discrepant default time zone that is assumed by "datetime". None of the arguments passed to the deployed function could possibly be responsible, nor any OS file or registry setting; this is because they are common to both scenarios (invocation from CMD or Bash). Furthermore, both the CMD and Bash scripts invoke identical "java" and "javac" binaries with identical arguments, e.g., arguments specifying JAR paths, including the Matlab Runtime.

The only possible cause that I can fathom is that "datetime" modifies its behaviour depending on environment variables. For Java, variable TZ is sometimes used to influence the time zone, but as mentioned above, the default time zone is not discrepant at the level of the Java code. Perhaps the "datetime" component of the Matlab Runtime decides on the default time zone based on one or more environment variables other than TZ. One possibility is that it checks environment variables to determine the OS or some aspect of it. For example, if "datetime" executes different logic depending on whether the OS is unix-based, then the unix-ish environment variables set by Cygwin might confuse "datetime" into behaving differently when invoked from Cygwin's Bash compared to CMD.

I have asked TMW to re-open the ticket so that I can provide the test files showing the nondiscrepant default timezone at the level of the Java code.

[Star Strider]

It will be interesting to know what the actual cause of the time zone problem is.

This is more complicated than I ever could have imagined.

[FM]

The solution in my case is not to assume that "datetime" uses the local time zone by default, but to explicitly tell it to do so via its arguments. This is only a solution for new code going forward. Any deployed code may not behave is it did when tested, depending on what factors in the environment causes this discrepant behaviour. So it would be best to eliminate the discrepancy in new versions of Matlab.

[James Tursa]

@FM Thanks for digging into this, btw. I would give you more votes if I could!

[FM]

No worries about the votes. I do hope that TMW sees it as worthwhile to track down and fix. It's disconcerting to know that deployed products may not behave as expected. I would do further troubleshooting if I could, but this was a discovered and unexpected issue, and my main task is something else.