I am trying to convert EPOC time to date time and need to extract the time only from that
I am doing below
$min = $Time_Start | measure -Minimum
$max = $Time_End | measure -Maximum
[datetime]$oUNIXDatemin=(Get-Date 01.01.1970)+([System.TimeSpan]::fromseconds($min.Minimum))
$oUNIXDatemin_1 = $oUNIXDatemin.ToString("HH:mm:ss")
[datetime]$oUNIXDatemax=(Get-Date 01.01.1970)+([System.TimeSpan]::fromseconds($max.Maximum))
$oUNIXDatemax_1 = $oUNIXDatemax.ToString("HH:mm:ss")
Problem is while converting I am getting $oUNIXDatemin_1 and $oUNIXDatemax_1 value like
$oUNIXDatemin_1
12 October 2021 07:46:46
$oUNIXDatemax_1
12 October 2021 21:16:04
My EPOC values are
$min.Minimum
1634024806
$max.Maximum
1634073364
Please let me know what is wrong here. Need to find the difference in HH:mm:ss format.
In PowerShell, you'd usually use a format string. Subtracting two PowerShell datetimes returns a value of type Timespan, which is well-behaved over a span of more than 24 hours.
([datetime]"12 October 2021 21:16:04" - [datetime]"12 October 2021 07:46:46") -f "HH:mm:ss"
13:29:18
Be careful here. Both intervals (durations) and time (of day) have the same format, but different meanings. For example, it makes sense to multiply the interval "01:00:00" (1 hour) by 3 to get three hours; it doesn't make sense to multiply the time "01:00:00" (1 o'clock AM) by 3.
I'm sure the overall calculation can be simplified, but it's too early for me.
Related
I use Jiffy for calculate the difference in between 2 date in month.
But I don't the good result.
For end = 2/4/2023 and start = 1/4/2022 I have 12 months.
For end = 1/4/2023 and start = 1/4/2022 I have 11 months (error: expected 12).
Thanks,
num month = Jiffy(end).diff(Jiffy(start), Units.MONTH);
Right now it is checking 12 at midnight to 12 at midnight of the end date which is 11 months 30 days. Now if the end date is one second greater than the correct date it should work. So a hackey solution is to add one day duration to the end date and check
end.add(duration(day:1))
I have column with cell format date or time (DD.MM.YYYY HH:MM:SS) and values like
03.12.2013 14:01:49
04.12.2013 10:19:27
04.12.2013 12:44:56
04.12.2013 14:20:12
04.12.2013 18:30:21
I need those values converted to unix epoch (seconds since 1970). Somehow it feels like the values are not recognized as dates, but rather as strings. I tried different formats, had little luck with dates without time.
Operations performed on date data should be automatic provided that the cells are formatted as as a user defined DD.MM.YYYY HH:MM:SS in the 'Format' > 'Cells' > 'Numbers' tab.
If you're using the standard settings, LibreOffice Calc uses 12/30/1899 as it's default date. So the first step is getting the number of days between 12/30/1899 and 1/1/1970:
=(DATE(1970,1,1) - DATE(1899,12,30)) = 25569
Number of seconds in a day:
=(60 * 60 * 24) = 86400
If, for example, in cell A2 you have the date 03.12.2013 14:01:49. I subtract the difference between Calc's default date and the Unix Epoch we just calculated, and multiply it by the number of seconds in a day:
=(A2 - 25569) * 86400
The result is a value of 1363096909 which is the Epoch time in seconds. If you need it in milliseconds, multiply the equation by 1000.
If it's something you use a lot, you can create a custom function that does this. Go to Tools > Macros > Edit Macros, and type out the following into whichever module comes up:
REM ***** BASIC *****
Function EPOCH(date_cell)
EPOCH = (date_cell - 25569)*86400
End Function
Close the macro IDE, and now you can use your EPOCH() like any other function!
This formula worked for me, where the others above did not:
= DATE( 1970, 1, 1 ) + ( A1 / 86400 )
As per MDN
"Date objects are based on a time value that is the number of milliseconds since 1 January, 1970 UTC."
Then why does it accept negative values ?
Even if it did shouldn't negative value mean values before Jan 1, 1970 ?
new Date('0000', '00', '-1'); // "1899-12-30T05:00:00.000Z"
new Date('0000', '00', '00'); // "1899-12-31T05:00:00.000Z"
new Date('-9999', '99', '99'); // "-009991-07-08T04:00:00.000Z"
What is happening ?
Update
For some positive values , the year begins from 1900
new Date(100); // "1970-01-01T00:00:00.100Z" // it says 100Z
new Date(0100); // "1970-01-01T00:00:00.064Z" // it says 64Z
new Date("0006","06","06"); // "1906-07-06T04:00:00.000Z"
Also note that, in the last one, the date is shown as 4 which is wrong.
I suspect this is some sort of Y2K bug ?!!
This is hard and inconsistent, yes. The JavaScript Date object was based on the one in Java 1.0, which is so bad that Java redesigned a whole new package.
JavaScript is not so lucky.
Date is "based on" unix epoch because of how it is defined. It's internal details.
1st Jan 1970 is the actual time of this baseline.
since is the direction of the timestamp value: forward for +ve, backward for -ve.
Externally, the Date constructor has several different usages, based on parameters:
Zero parameters = current time
new Date() // Current datetime. Every tutorial should teach this.
The time is absolute, but 'displayed' timezone may be UTC or local.
For simplicity, this answer will use only UTC. Keep timezone in mind when you test.
One numeric parameter = timestamp # 1970
new Date(0) // 0ms from 1970-01-01T00:00:00Z.
new Date(100) // 100ms from 1970 baseline.
new Date(-10) // -10ms from 1970 baseline.
One string parameter = iso date string
new Date('000') // Short years are invalid, need at least four digits.
new Date('0000') // 0000-01-01. Valid because there are four digits.
new Date('1900') // 1900-01-01.
new Date('1900-01-01') // Same as above.
new Date('1900-01-01T00:00:00') // Same as above.
new Date('-000001') // 2 BC, see below. Yes you need all those zeros.
Two or more parameters = year, month, and so on # 1900 or 0000
new Date(0,0) // 1900-01-01T00:00:00Z.
new Date(0,0,1) // Same as above. Date is 1 based.
new Date(0,0,0) // 1 day before 1900 = 1899-12-31.
new Date(0,-1) // 1 month before 1900 = 1899-12-01.
new Date(0,-1,0) // 1 month and 1 day before 1900 = 1899-11-30.
new Date(0,-1,-1) // 1 month and *2* days before 1900 = 1899-11-29.
new Date('0','1') // 1900-02-01. Two+ params always cast to year and month.
new Date(100,0) // 0100-01-01. Year > 99 use year 0 not 1900.
new Date(1900,0) // 1900-01-01. Same as new Date(0,0). So intuitive!
Negative year = BC
new Date(-1,0) // 1 year before 0000-01-01 = 1 year before 1 BC = 2 BC.
new Date(-1,0,-1) // 2 days before 2 BC. Fun, yes? I'll leave this as an exercise.
There is no 0 AC. There is 1 AC and the year before it is 1 BC. Year 0 is 1 BC by convention.
2 BC is displayed as year "-000001".
The extra zeros are required because it is outside normal range (0000 to 9999).
If you new Date(12345,0) you will get "+012345-01-01", too.
Of course, the Gregorian calendar, adopted as late as 1923 in Europe, will cease to be meaningful long before we reach BC.
In fact, scholars accept that Jesus wasn't born in 1 BC.
But with the stars and the land moving at this scale, calendar is the least of your worries.
The remaining given code are just variations of these cases. For example:
new Date(0100) // One number = epoch. 0100 (octal) = 64ms since 1970
new Date('0100') // One string = iso = 0100-01-01.
new Date(-9999, 99, 99) // 9999 years before BC 1 and then add 99 months and 98 days
Hope you had some fun time. Please don't forget to vote up. :)
To stay sane, keep all dates in ISO 8601 and use the string constructor.
And if you need to handle timezone, keep all datetimes in UTC.
Well, firstly, you're passing in string instead of an integer, so that might have something to do with your issues here.
Check this out, it explains negative dates quite nicely, and there is an explanation for your exact example.
Then why does it accept negative values ?
You are confusing the description of how the data is stored internally with the arguments that the constructor function takes.
Even if it did shouldn't negative value mean values before Jan 1, 1970 ?
No, for the above reason. Nothing stops the year, month or day from being negative. You just end up adding a negative number to something.
Also note that, in the last one, the date is shown as 4 which is wrong.
Numbers which start with a 0 are expressed in octal, not decimal. 0100 === 64.
Please have a look at the documentation
Year: Values from 0 to 99 map to the years 1900 to 1999
1970 with appropriate timezone: new Date(0); // int MS since 1970
1900 (or 1899 with applied timezone): new Date(0,0) or new Date(0,0,1) - date is 1 based, month and year are 0 based
1899: new Date(0,0,-1)
I have 2 times stored in character arrays in MATLAB.
a = '11:00 PM'
b = '07:30 AM'
I want to find the difference in hours between the 2 times, which should be 8.5 hours in this example. Is there any short method to do that? I can datenum both numbers, subtract them, datevec the difference, extract the hours and minutes from the vector, and convert them into hours, but this takes a lot of lines. Is there a more efficient way of doing this or is there an existing function?
You can do this by converting each string using datetime, taking the difference, then converting the result with hours:
numHours = hours(diff(datetime({a; b}, 'InputFormat', 'hh:mm a')));
numHours = numHours + 24.*(numHours < 0)
numHours =
8.5000
The second line accounts for the condition in your example, where the second time has to occur on the next day for the time difference to be positive, so 24 hours are added to the (negative) difference.
add a date to the time
like
a = '1/1/2000 11:00 PM'
b = '1/1/2000 07:30 AM'
the convert the string to datetime
x=str2num(strrep(a,':',''))
y=str2num(strrep(b,':',''))
then fine the difference between 2 dates
e = etime(x,y)
this will give you number of seconds between both times
I am looking for helping doing time conversions from UTC time to string using MATLAB.
I am trying to extract time from a data file collected at the end of October 2010.
The data file says it is reporting in UTC time and the field is an integer string value in milliseconds that is around 3.02e11. I would like to convert this to a string but am have some trouble.
I figured out that the units are most definitely in milliseconds so I convert this to fractions of days to be compatible with datenum format.
If the data was collected at the end of October (say, October 31, 2010) then I can guess what kind of number I might get. I thought that January 1, 2001 would be a good epoch and calculated what sort of number (in days) I might get:
suspectedDate = datenum('October 31, 2010')
suspectedEpoch = datenum('January 1, 2001')
suspectedTimeInDays = suspectedDate - suspectedEpoch
Which comes out as 3590.
However, my actual time, in days, comes out with the following code
actualTime = 3.02e11
actualTimeInDays = 3.02e11/1000/24/3600
as 3495.4.
This is troubling as the difference is only 94.6 -- not a full year. This would mean either the documentation for the file is wrong or the epoch is close to April 1-5, 2001:
calculatedEpoch = suspectedDate - actualTimeInDays
calculatedEpochStr = datestr(calculatedEpoch)
Alternately, if the epoch is January 1, 2001 then the actual date in the file is from the end of July.
ifEpochIsJanuaryDate = suspectedEpoch + actualTimeInDays
ifEpochIsJanuaryDateStr = datestr(ifEpochIsJanuaryDate)
Is this a known UTC format and can anyone give suggestions on how to get an October date from 3.02e11 magnitude number?
Unix time today is about 13e11, and is measured in ms since 1970.
If your time is ~3e11, then it's probably since year 2000.
>> time_unix = 1339116554872; % example time
>> time_reference = datenum('1970', 'yyyy');
>> time_matlab = time_reference + time_unix / 8.64e7;
>> time_matlab_string = datestr(time_matlab, 'yyyymmdd HH:MM:SS.FFF')
time_matlab_string =
20120608 00:49:14.872
Notes:
1) change 1970 into 2000 if your time is since 2000;
2) See the definition of matlab's time.
3) 8.64e7 is number of milliseconds in a day.
4) Matlab does not apply any time-zone shifts, so the result is the same UTC time.
5) Example for backward transformation:
>> matlab_time = now;
>> unix_time = round(8.64e7 * (matlab_time - datenum('1970', 'yyyy')))
unix_time =
1339118367664
You can't just make up your own epoch. Also datenum returns things in days. So the closeness you got with doing your math was just a coincidence.
Turns out that
>> datenum('Jan-1-0000')
ans =
1
and
>> datenum('Jan-1-0001')
ans =
367
So Matlab should be returning things in days since Jan. 1, 0000. (Not a typo)
However, I'd look carefully at this 3.02e11 number and find out exactly what it means. I'm pretty sure it's not standard Unix UTC, which should be seconds since January 1, 1970. It's way too big. It's close to GMT: Mon, 1 Jan 11540 08:53:20 UTC.