On 5/8/2018 6:45 AM, GS wrote:
Thanks for the details, ..very interesting stuff!

I still say "the language" does no such thing; the language may or may
not include the library but it's entirely up to the developer to use
whatever package or encoding they choose.

Well I'm going to flatly assert that you're wrong based on the 5/6
languages I've studied/used because all of them returned a DateSerial
property for values stored in Date data Types. (I'm not just a VB[A]
guy)<g

Of course the native or companion library will return its type; it can
hardly do anything else. :) But...that's not of which I speak here.

You're conflating different things...that there _may_ be an intrinsic
Date data type has no bearing upon whether the developer does/does not
use it for any give application or feature within an application built
in the language. Of course, if the language either natively or with a
companion library supports such a thing, it only makes sense to use it.
Returning to the subject here that the OP has time stamps as text
strings from a data acq app, it's quite possible all it does is read a
real-time clock and never does anything except record that as a string
and so never has a time-type variable of whatever ilk the development
language may support.

Fortran doesn't have a native date type at all; in Matlab, the original
datenum is just a double and while is a serial number doesn't use the
same epoch as does Excel (there are supplied translation routines).

With the introduction of OOP features into Matlab, Mathworks has begun
implementing new classes, the datetime() is one which is an enhancement
of datenum implemented as an opaque object with methods and properties
that provide similar functionality as you're used to with Excel
operations on its Date. There's another whole thing called a
timetable() that is a rectangular collection of things associated with a
specific time sequence that is intended for such things as what it
appears the OP has here.

How Excel interprets date values has nothing to do with VB[A]; - it just
happens to also be a function of how spreadsheets work. (I'm also not
just an Excel guy)<g

Again, POV...spreadsheets work how they do because that's the way the
developers used the underlying programming language to make them work!
That they used the base features of that language as model or directly
is hardly surprising and then build upon those to provide for the
specific desired functionality. How MS chose to interpret input dates
in Excel has to do with their penchant for thinking the world should
rotate around MS as much as anything else; that the system has no way
other than global change to the locale setting for importing dates from
alternate sources is symptomatic.

OTOH, Matlab has the facility to read from whatever input source in a
user-defined format for any particular variable including conflicting
definitions for two adjacent columns in the same data file if that were
to be the way the data had been produced. AFAICT, that's not possible
in Excel without either first preprocessing the data to produce either a
system-locale consistent format, an unambiguous format recognizable by
Excel or to force to not be interpreted as dates at all and do the
conversion internally. In my view, "that's just rude!" and negates much
of the point of having a general programming language if one can't truly
be general; it's the computer that should bow to the user, not the other
way 'round.

$0.02, imo, ymmv, etc., etc., etc., ... :)


To illustrate, an example of what the OP might be encountering as I
understand it. The following is cut 'n paste from the Matlab command
window to answer more about what interactive input "looks like". No,
one doesn't have to quote strings as input nor is it a string-processing
language like REXX (altho to input to a string variable that text would
have to be quoted, of course, to prevent the interpreter from trying to
execute whatever the text was as code).

type dates.txt % a short data file contains two ambiguous dates
5/6/2018, 5/6/2018

1) Read as m/d/yyyy for both...


readtable('dates.txt','readvariablenames',0,'forma t',repmat('%{M/d/yyyy}D',1,2))
ans =
1×2 table
Var1 Var2
________ ________
5/6/2018 5/6/2018
month(ans{1,:}) % see what we got...
ans =
5 5

2) now presume one is from that other data acq system we can't change...


readtable('dates.txt','readvariablenames',0,'forma t',['%{M/d/yyyy}D','%{d/M/yyyy}D'])
ans =
1×2 table
Var1 Var2
________ ________
5/6/2018 5/6/2018
month(ans{1,:}) % see what we got...
ans =
5 6


Indeed, we got the two imported correctly even though they have
different encodings and are visually ambiguous--much better scenario
than having to try to guess and figure out after the fact what Excel did
behind our back.

By default, Matlab keeps the input format for display format so both
still visually look the same; we can fix that, too--


d2=readtable('dates.txt','readvariablenames',0,'fo rmat',['%{M/d/yyyy}D','%{d/M/yyyy}D']);
d=d2.Var2; % retrieve to work on one variable
d.Format='M/d/yyyy'; % make formatting consistent for all
d2.Var2=d % put back into the table...
d2 =
1×2 table
Var1 Var2
________ ________
5/6/2018 6/5/2018


One can use whatever display format wanted, of course, so can also use

d.Format='dMMMyyyy'
d =
datetime
5Jun2018


And, of course, there also operations on them as one would expect--

d2.Var2-d2.Var1
ans =
duration
720:00:00
days(ans)
ans =
30


The duration type also has format property for display, default is hours
and there are operations for fixed 24-hr days or calendar durations
depending on whether it's pure time or calendar time one is interested
in, etc., etc., etc., ...

Just scratching the surface; if you were interested, there's Octave
which is a Matlab workalike--it has _most_ of what Matlab has in base
product with some other features that aren't (and vice versa). I've not
checked but I presume by now it has similarly functional datetime class.

--