Python Forum

Full Version: How to convert different timestamp formats?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
I have timestamp values of different format. For one format, I used the function below and it worked. The original timestamp value is this format: 735510.451215
The other file has a timestamp value in this format: 42737.614433

The first timestamp is in unix form and using the function below i was able to get the actual timestamp:

#function to convert unix timestamp
def matlab2datetime(matlab_datenum):
    day = datetime.fromordinal(int(matlab_datenum))
    dayfrac = timedelta(days=matlab_datenum%1) - timedelta(days = 366)
    return day + dayfrac
matlab2datetime(735510.451215)
Result: datetime.datetime(2013, 10, 3, 10, 49, 44, 976001)

Using the same function for the other value results in the following output:

matlab2datetime(42737.614433)
Result: datetime.datetime(117, 1, 3, 14, 44, 47, 11200)

What is the difference between these two timestamp formats and how can I change the function to deal with the second type? Thank you
Are you sure its a unix timestamps? Neither are correct if so. Unix timestamps are seconds since January 1st 1970 (UTC). The unix timestamp of writing this post was 1565016518.

You timestamps if unix are:
Quote:735510.451215
Is equivalent to:
01/09/1970 @ 12:18pm (UTC)
and
Quote:42737.614433
Is equivalent to:
01/01/1970 @ 11:52am (UTC)
for unix timepstamp epoch is January 1st 1970 (UTC).
in your code you use datetime.fromordinal:
Quote:Return the datetime corresponding to the proleptic Gregorian ordinal, where January 1 of year 1 has ordinal 1. ValueError is raised unless 1 <= ordinal <= datetime.max.toordinal(). The hour, minute, second and microsecond of the result are all 0, and tzinfo is None.
so there is 1970 years error introduced by your code alone
more over in unix time stamp 42737 and 735510 would be whole seconds, not days.

if they are indeed unix timestamps you need to use detetime.fromtimestamp()
>>> from datetime import datetime
>>> datetime.fromtimestamp(735510.451215)
datetime.datetime(1970, 1, 9, 14, 18, 30, 451215)
>>> datetime.fromtimestamp(42737.614433)
datetime.datetime(1970, 1, 1, 13, 52, 17, 614433)
(Aug-05-2019, 03:23 PM)buran Wrote: [ -> ]for unix timepstamp epoch is January 1st 1970 (UTC).
in your code you use datetime.fromordinal:
Quote:Return the datetime corresponding to the proleptic Gregorian ordinal, where January 1 of year 1 has ordinal 1. ValueError is raised unless 1 <= ordinal <= datetime.max.toordinal(). The hour, minute, second and microsecond of the result are all 0, and tzinfo is None.
so there is 1970 years error introduced by your code alone
more over in unix time stamp 42737 and 735510 would be whole seconds, not days.

if they are indeed unix timestamps you need to use detetime.fromtimestamp()
>>> from datetime import datetime
>>> datetime.fromtimestamp(735510.451215)
datetime.datetime(1970, 1, 9, 14, 18, 30, 451215)
>>> datetime.fromtimestamp(42737.614433)
datetime.datetime(1970, 1, 1, 13, 52, 17, 614433)

The output I am getting for the first value is what I am expecting, maybe it is not unix but I am getting the date and time as expected but for the second one, I am not sure why it is returning a different timestamp format compared to the first one.
I would say this is because the second one is using a different starting point. The first one, if it is getting the correct date with fromordinal, is the days since 1/1/0001. If the second one is the same date, it is starting from some other point in time. As buran pointed out, Unix starts from 1/1/1970 (but counts seconds, not days).

However, That starting point should be fromordinal(first - second). That date is September 29th, 1897. I can't think of any reason to start a time standard from that date. So I think your assumption about the second one being the same date as the first one is wrong.

You need to track down the source of the second number, and find out what method they are using to encode a date into that number.
I am getting the same result for the first timestamp using this command in matlab
t = datetime(735510.451215,'ConvertFrom','datenum')

03-Oct-2013 10:49:44

for the second timestamp i am getting a weird value as below:
t = datetime(42737.614433,'ConvertFrom','datenum')

03-Jan-0117 14:44:47
(Aug-05-2019, 05:37 PM)python_newbie09 Wrote: [ -> ], I am not sure why it is returning a different timestamp format compared to the first one.
the format is presumably the same (i.e. if you have consistent data). the format comes from your data, it's not something that comes from the code. you need to KNOW what you are dealing with in order to process your data correctly.
(Aug-05-2019, 05:52 PM)python_newbie09 Wrote: [ -> ]03-Jan-0117 14:44:47
it's the same what you get with python 3 January 117. So you need to check your data if that's not waht you expect
you know the saying - garbage in, garbage out, right?
(Aug-05-2019, 05:50 PM)ichabod801 Wrote: [ -> ]I would say this is because the second one is using a different starting point. The first one, if it is getting the correct date with fromordinal, is the days since 1/1/0001. If the second one is the same date, it is starting from some other point in time. As buran pointed out, Unix starts from 1/1/1970 (but counts seconds, not days).

However, That starting point should be fromordinal(first - second). That date is September 29th, 1897. I can't think of any reason to start a time standard from that date. So I think your assumption about the second one being the same date as the first one is wrong.

You need to track down the source of the second number, and find out what method they are using to encode a date into that number.

Yes i know the second timestamp has a different encoding compared to the first one and that's what I am trying to figure out now. They are matlab files and it's really painful with these files somehow being saved with different encodings :(
(Aug-05-2019, 05:54 PM)python_newbie09 Wrote: [ -> ]timestamp has a different encoding compared to the first one and that's what I am trying to figure out now. They are matlab files and it's really painful with these files somehow being saved with different encodings
encoding is something different and it has nothing to do with timestamp format.
Pages: 1 2