I've developed an iOS app that collects data from both the phone's accelerometer and gyroscope, and it should process some data and send it over to the cloud.
The issue is that the CMAccelerometerData for ex. is based on CMLogItem which stores the timestamp as 'the amount of time in seconds since the phone booted' (apple documentation).
In order to find the real time in epoch (seconds since 1/1/1970) i tried to use NSProcessInfo().systemUptime, but it turned out that this value isn't accurate in some cases and gave me an offset of up to few hours!
In some posts it's mentioned that the uptime parameter is affected by system sleeps, and that could be the issue for these offsets (i must mention that when debugging there's no offset at all).
Any idea how can i get the timestamp of a CMLogItem?
(even getting a 'close enough' timestamp is enough, i can skip the milli-seconds accuracy...)
Thanks in advance!
If I've understood your question correctly, CMAccelerometerData and CMLogItem are not the types you need to work with.
CMSensorRecorder.accelerometerData(from:to:) returns CMSensorDataList, which allows to iterate over CMRecordedAccelerometerData objects, and each of them have startDate: Date parameter.
Additionaly, following extension will make iteration over samples easier:
extension CMSensorDataList: Sequence {
public func makeIterator() -> NSFastEnumerationIterator {
return NSFastEnumerationIterator(self)
}
}
Related
I have been trying for hours to get , what I thought to be, a simple if-then-else statement to work in IBM Cognos / Report Studio 10.0.
I am simply trying to create a data item in a query, to decide which day of the week a date is, and then return a calculated date.
if (cast(_day_of_week([Expected Delivery Date],1), integer) = 1)
then (_add_days([Expected Delivery Date],2))
else (current_date)
The back end database is Informix. I am receiving the error "Corresponding data types must be compatible in CASE expression or DECODE".
I have tried every variant I can think of: with/without cast, using case/when/then. I have created a separate data item also:
[Calc Day of Week] (Data Item - calculates correctly)
cast(_day_of_week([Expected Delivery Date],1), integer)
[Calc Exp Despatch Date] (Data Item)
if ([Calc Day of Week] = 1)
then (_add_days([Expected Delivery Date],2))
else (current_date)
Even when using that data item in my next data item, I get the same error.
I can only think that it doesn't understand that I am basing the comparison on an integer and attempting to return a date - but if that is the case, how do I create a data item to perform such a calculation?
Any help is greatly appreciated.
The error is saying that the data types of the THEN and ELSE parts are different. Your first step is to determine the data types. You don't mention if you have done that with the calculations that you mention. They seem to be concentrating on the IF part of the function.
The basic technique is called divide and conquer. A more elegant wording is, controlling the variables or isolating the components.
_day_of_week returns an int so I don't know why you are doing the casting. (_day_of_week([Expected Delivery Date] = 1 ) should be sufficient but that's for later.
Take _add_days([Expected Delivery Date],2). Put it into an expression and find out the data type which is returned.
Compare that data type with current_date.
Current_date returns a date. What is the data type of expected delivery date? date or datetime?
If the data types are different then your approach would be to modify one or the other to match the other. For example, cast _add_days([Expected Delivery Date],2) to date if it is a date time. Or use current_timestamp but I don't use it so I can't speak much about it.
If you use 1=1 and 1<>1 in place of what you have for your if part then you can control the flow of the expression and verify that the error is coming from the then and else bits.
Here's something, for another application, but valid in outlining testing techniques.
https://www.ibm.com/support/pages/corresponding-types-must-be-compatible-case-expression
In java long timestamp is as 8 bytes.
What is the size of NSDate in objective-c and swift ?
In iOS data type size are respectively.
Integer data types in OS X and iOS:
Floating-point data types in OS X and iOS:
Source.
While you are asking the size of NSDate, its a class not a primitive data type where you can create its object to access its member function and variables. When an object is created the memory is allocated in HEAP.
You can use sizeof() method in both Swift and Objective c to get the size of any data type.
You should reword your question to clarify what you're actually trying to do. The size of a time stamp on any platform is irrelevant to the question of storing the time stamp on the server. Storing the time stamp as raw bytes means it's not portable between devices and/or platforms. Better to encode the time stamp as a date string and send that to the server for storage.
How the server stored it is another, much broader question, but the basic options are as a string or in some internal format to be converted to/from a string as needed, depends a lot on what you're going to actually do with it on the server.
While we're at it, make sure that you take time zone into account, or, better yet, always use UTC for time stamps.
I want to offer the user the choice of imperial or metric measurement of weight in my app to increase audience suitability. I have designed the following below to allow me to determine which setting the user wishes to use.
However, im unsure how I would go about applying the metric selection to the whole rest of the app? Would it be a case of setting the app reach into each object the user has created in coredata and all text labels relating to a weight measurement and alter their weight property by multiplication or division each time the user changes weight system?
Appreciate any insight into how I may achieve this as I didnt want to go too far in the wrong direction!
func convertAppMetric() {
if self.userSelectedWeightSystem == "Metric" {
print("THE USER SET THE APP TO METRIC, CONVERTING FIGURES...")
//some code
} else if self.userSelectedWeightSystem == "Imperial" {
print("THE USER SET THE APP TO IMPERIAL, CONVERTING FIGURES...")
//some other code
}
}
This is going to be one of those answers that SO hates, but you want to go read up on NSMeasurement.
NSMeasurement holds both a value and a Unit, the later of which is the original measurement type. You store all your data in the format that was originally provided - if the user puts in pounds, store a NSMeasurement with 182 pounds. If they put in kg, make one with 90 kg. You can even put in your own Units, like stone.
From then on, always present the data using an NSMeasurementFormatter. You can pass in the output type, which in your case is the global setting you mentioned in your question. This means that no matter what unit they provided, it always comes out properly converted to the one you want, and changing it instantly changes it everywhere.
Its easy to make your own converters for weird units. I made one for decimal inches and feet/inches, so 13.5 inches turns into 1' 1.5".
Looking at the docs there is a descrepancy between the data in a checkin object for the query API s the push API with regards to timeZone.
According to https://developer.foursquare.com/overview/realtime a sample push will contain the name of the tz eg America/New_York
However according to https://developer.foursquare.com/docs/responses/checkin (and the API explorer) a checkin object will contain the timeZone offset eg 60 for GMT+1
I havn't managed to confirm whats in the Push API myself yet as I hav to setup the SSL certs, can anyone confirm of the docs are correct and we do indeed have 2 type of tz format. I would have thought that including the timeZone rather than the offset would be better as this doesn't vary with Daylight Savings unlike the figure. Europe/London will always be a constant where as the offset will switch between 0 and 60 mins
I'm not directly familiar with FourSquare's API, so I can't confirm or deny this for you. But I can tell you there are often cases where you would use both.
It is ok to only present an offset, if the data represents a particular time. Since the checkin response provides a createdAt date/time as an integer seconds since epoch (aka a "Unix Timestamp"), then it is appropriate to provide a separate offset. (Although I find it interesting that they provide the offset as a string and not as an integer number of minutes.) The other way you might do this would be with a single DateTimeOffset values, usually presented in ISO8601 format, as in 2013-06-02T01:23:45-07:00. Either are acceptable.
But as you may be aware, an offset does not uniquely identify a time zone. In the case of a single event, it doesn't need to. But if it were a recurring event, or if there was a possibility that you might want to modify the time value, then an offset alone would not suffice. That's when you need the full zone identifier.
If you have a zone identifier such as America/New_York, then you can always find out what the correct offset for any date/time would be. But not everyone has a TZDB implementation readily available. For example, in .Net on Windows, you get Microsoft's clumsy time zone database by default, and you have to find a library (like NodaTime) if you want to use the TZDB zones.
It does seem strange that the push and pull for the same type of action (a check-in) would have different values just because they were going through different APIs. My advice (to Foursquare) would be threefold:
Be consistent about the data for the same activity, regardless of push vs pull.
Provide both the TZDB identifier, and the the UTC offset associated with the event.
Provide the event's timestamp and offset in a single value, as an ISO8601 formatted string, rather than a unix time integer.
The Foursquare documentation is correct but a bit incomplete (as of time of posting). The check-in response contains a timeZoneOffset field. The real-time push response has a timeZone field and a timeZoneOffset field—the timeZone field is still there for legacy purposes.
Thanks for pointing this out; we'll update the docs to reflect that timeZoneOffset is the preferred method at this point. As Matt mentioned, the offset method is a better way to identify a particular time from createdAt.
I am using the NWS REST API as my weather service for an app I am making. I was initially reluctant to use NWS because of its bad documentation, but I couldn't resist as it is offered completely free.
Now that I am trying to use it, I am running into some difficulty. When making a request for multiple days, the minimum temperature appears nil for several days.
(EDIT: As I have been testing the API more I have found that it is not always the minimum temperatures that are nil. It can be a max temp or a precipitation, it seems completely random. If you would like to make test calls using their web interface, you can do so here: http://graphical.weather.gov/xml/sample_products/browser_interface/ndfdBrowserByDay.htm
and here: http://graphical.weather.gov/xml/sample_products/browser_interface/ndfdXML.htm)
Here is an example of a request the minimum temperatures are empty: http://graphical.weather.gov/xml/sample_products/browser_interface/ndfdBrowserClientByDay.php?listLatLon=40.863235,-73.714780&format=24%20hourly&numDays=7
Surprisingly, on their website, the minimum temperatures are available:
http://forecast.weather.gov/MapClick.php?textField1=40.83&textField2=-73.70
You'll see under the Minimum temperatures that it is filled with about 5 (sometimes less, it is inconsistent) blank fields that say <value xsi:nil="true"/>
If anybody can help me it would be greatly appreciated, using the NWS API can be a little overwhelming at times.
Thanks,
The nil values, from what I can understand of the documentation, here and here, simply indicate that the data is unavailable.
Without making assumptions about NOAA's data architecture, it's conceivable that the information available via the API may differ from what their website displays.
Missing values are represented by an empty element and xsi:nil=”true” (R2.2.1).
Nil values being returned seems to involve the time period. Notice the difference between the time-layout keys (see section 5.3.2) in 1 in these requests:
k-p24h-n7-1
k-p24h-n6-1
The data times are different.
<layout-key> element
The key is derived using the following convention:
“k” stands for key.
“p24h” implies a data period length of 24 hours.
“n7” means that the number of data times is 7.
“1” is a sequential number used to keep the layout keys unique.
Here, startDate is the factor. Leaving it off includes more time and might account for some requested data not yet being available.
Per documentation:
The beginning day for which you want NDFD data. If the string is empty, the start date is assumed to be the earliest available day in the database. This input is only needed if one wants to shorten the time window data is to be retrieved for (less than entire 7 days worth), e.g. if user wants data for days 2-5.
I'm not experiencing the randomness you mention. The folks on NOAA's Yahoo! Groups forum might be able to tell you more.