Say the EPOCH timestamp I received from an API is 1595216214.
It is equivalent to Monday, July 20, 2020 3:36:54 AM (GMT).
My interest is time value only (Ignoring the date/day value)? How can I code in Dart?
Also, how can I convert it into my time zone (E.g.: GMT+8)
you can use DateTime class to do that. Like this:
var dateUtc = DateTime.fromMillisecondsSinceEpoch(myAPIEpochTimeInMilliseconds, isUtc: true);
var dateInMyTimezone = dateUtc.add(Duration(hours: 8));
var secondsOfDay = dateInMyTimezone.hour * 3600 + dateInMyTimezone.minute * 60 + dateInMyTimezone.second;
NOTE:
If you are doing this for the web, although Dart does support 64+ bit numbers, javascript only takes 32-bit integers. So, use the BigInt class for big numbers tha exceeds 32-bit representation.
DateTime doesn't have an inherent timezone to be defined on the class. Is either the local (machine) time or utc Time. So, it is recomended to always use utc and add timezone offset when needed. Or just create a wrapper.
Related
What's the current time Date object time precision when it is initiated using Date()? Does it capture the time to milliseconds?
let currentTime = Date()
print(currentTime) // 2022-10-09 09:13:39 +0000
When I print the date it only shows 2022-10-09 09:13:39 +0000 so I wonder if its precision is only to the second.
Does it capture the time to milliseconds?
Yes, it does. printing a date shows a fixed string description omitting the fractional seconds. A hint is that TimeInterval is defined as a floating point type (Double).
You can prove it
let interval = Date().timeIntervalSince1970
print(interval)
which shows a real fractional part rather than a Is-floating-point-math-broken value like .00000003
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 )
I'm adding a second to an instance of Foundation's date, but the result is off by an entire minute.
var calendar = Calendar(identifier: .iso8601)
calendar.locale = Locale(identifier: "en")
calendar.timeZone = TimeZone(identifier: "GMT")!
let date1 = Date(timeIntervalSinceReferenceDate: -62544967141.9)
let date2 = calendar.date(byAdding: DateComponents(second: 1),
to: date1,
wrappingComponents: true)!
ISO8601DateFormatter().string(from: date1) // => 0019-01-11T22:00:58Z
ISO8601DateFormatter().string(from: date2) // => 0019-01-11T21:59:59Z
Interestingly, one of the following makes the error go away:
round time interval since reference date
don't add time zone to calendar
set wrappingComponents to false (even though it shouldn't wrap in this case)
I don't really need sub-second precision in my code, so I created this extension that allows me to discard it.
extension Date {
func roundedToSeconds() -> Date {
return Date(timeIntervalSinceReferenceDate: round(timeIntervalSinceReferenceDate))
}
}
I want to know this:
Why does this error happen?
Am I doing something wrong?
Is there any issue with my workaround?
Why does this error happen?
I would say this is a bug in Core Foundation (CF).
Calendar.date(byAdding:to:wrappingComponents:) calls down to the internal Core Foundation function _CFCalendarAddComponentsV, which in turn uses the ICU Calendar C API. ICU represents a time as an floating-point number of milliseconds since the Unix epoch, while CF uses a floating-point number of seconds since the NeXT reference date. So CF has to convert its representation to ICU's representation before calling into ICU, and convert back to return the result to you.
Here's how it converts from a CF timestamp to an ICU timestamp:
double startingInt;
double startingFrac = modf(*atp, &startingInt);
UDate udate = (startingInt + kCFAbsoluteTimeIntervalSince1970) * 1000.0;
The modf function splits a floating-point number into its integer and fractional parts. Let's plug in your example date:
var startingInt: Double = 0
var startingFrac: Double = modf(date1.timeIntervalSinceReferenceDate, &startingInt)
print(startingInt, startingFrac)
// Output:
-62544967141.0 -0.9000015258789062
Next, CF calls __CFCalendarAdd to add one second to -62544967141. Note that -62544967141 lies in the round one-minute interval -62544967200 ..< -62544967140.0. So when CF adds one second to -62544967141, it gets -62544967140, which would be in the next round one-minute interval. Since you specified wrapping components, CF isn't allowed to change the minute part of the date, so it wraps back to the beginning of the original round one-minute interval, -62544967200.
Finally, CF converts the ICU time back to a CF time, adding in the fractional part of the original time:
*atp = (udate / 1000.0) - kCFAbsoluteTimeIntervalSince1970 + startingFrac + (nanosecond * 1.0e-9);
So it returns -62544967200 + -0.9000015258789062 = -62544967200.9, exactly 59 seconds earlier than the input time.
Am I doing something wrong?
No, the bug is in CF, not in your code.
Is there any issue with my workaround?
If you don't need sub-second precision, your workaround should be fine.
I can reproduce it with more recent dates but so far only with negative reference dates, e.g. Date(timeIntervalSinceReferenceDate: -1008899941.9), which is 1969-01-11T22:00:58Z.
Any negative timeIntervalSinceReferenceDate in the last second of a minute interval should cause the problem. The bug effectively makes the first round whole minute prior to time 0 span from -60.99999999999999 through -1.0, but it should span from -60.0 through -5e324. All more-negative round minute intervals are similarly offset.
Is there a method in matlab to convert seconds from a known date to a standard date time format?
For example, if I have a vector of values shown as seconds from 1901/01/01, how would I convert them to a dateTime? In this case a value of 28125 would correspond to 1981/01/01. Is there an efficient method for doing this?
The numbers in your example do not make sense so it is not clear if your time is in seconds or days but since you asked for seconds I will use this.
What you want to achieve can be done using datenum function. This function returns the number of (fractional) days from 1/1/0000. So first you need to find your offset, e.g.:
offsetInDays = datenum(1901,1,1);
Next, you convert the date from seconds to days:
dateInDays = YourRequiredDateInSec * 3600 * 24;
Finally, you date is given by
RequiredDate = datestr(offsetInDays + dateInDays);
I am trying to parse some given date string:
val strDate = "2014-01-01T00:00:00.000999+00:00"
val dateFormatter = forPattern("yyyy-MM-dd'T'HH:mm:ss.SSSSSSZZ").withOffsetParsed()
val date = parse(strDate, dateFormatter)
but println(date) outputs 2014-01-01T00:00:00.000Z and
dateFormatter.print(date) returns 2014-01-01T00:00:00.000000+00:00.
I don't understand why the parser only gets 3 fraction of second digits instead of 6 as specified. Can someone explain this ?
EDIT: as #Jesper pointed out, the precision is limited to milliseconds.
Open the org.joda.time.base.BaseDateTime class, you'll see that the time is encoded as:
/** The millis from 1970-01-01T00:00:00Z */
private volatile long iMillis;
That the degree of precision you want can be stored via Joda.
The alternative is to use JSR-310.
if you have Java 8, it's already included.
add a dependency to threeten, then backport for older Java versions.
The base class is Instant which has a nanosecond precision, see: https://github.com/ThreeTen/threetenbp/blob/master/src/main/java/org/threeten/bp/Instant.java