Why to store date as timestamps? - date

I am creating a node app with mongo and trying to store createdOn field. I have two options, either go with the ISO date format("YYYY-MMM-DDThh:mm:ss.zzz") or use timestamp. My users will be mostly in India but my server is in Oregon USA, and all computation will be done over there. Just wanted your thoughts on which one to use and why?Could not find a nice blog post searching this. I hope the smart people who have already done this would help a fellow newbie out.
What am I already doing?
I am saving the date in the date time format,using momentTimeZone by Asia/Kolkata time and extracting it out. It's very painful and I have to remember that every time I write anything related to date I have to first convert it into IST and then proceed with any ops. Hence require your suggestion, whether to continue like this or try timestamp approach

Related

Alexa skills custom slot for date times

So, I'm working a project with the Amazon Echo. My goal is to record when I did a specific action and to record it into a DB. My issue is timezones, and I avoid this by using epoch time. However, from what I can tell of custom slots for an intent, my choices are formatted date strings with no time, or formatted time strings with no dates, and on top of all of that, I have no way of grabbing the client's timezone without specifically asking for it based on some forum posts I found with my google fu.
Does the echo just hate dates? This seems like something that should be really easy, but I'm struggling to figure out how to go about it without being really awkward and asking where they live so I can do a lookup of their timezone. I already had to make a pivot from telling them the specific time they did something to how long ago they did something because I can't pass dates back to the Echo and expect it to translate it. Is this another silly pivot I have to make?
Correct, you cannot get the client's TZ or location from Alexa. It's a privacy issue. The only way is to ask for it yourself.
There is a custom slot for "five digit number" which is perfect for ZIP code. That is the simplest way to get a user's approximate location.
If you want to get more inventive, since the Echo is (pretty much) only used in America, you only have to narrow it down to one of four time zones. (At the expense of Alaska, Hawaii and Arizona for half the year.) You could just ask which timezone they are in, which is less intrusive.
Or, if you want to get creative, make a joke out of it.
A: "Pop quiz: Are you in Eastern Standard time?"
U: "No"
A: "Drat. Let me guess again. You seem like a Mountain Time person."
...
Yes. It is an irritating limitation. But if you can find a novel way to work around it your skill will be more endearing.
It looks like you cannot (yet) detect the user's timezone, but you should still be able to achieve your goals. A few thoughts:
You could just make the system ignorant of timezones altogether. Each user may have a different timezone, but all times for a particular user will be in the same timezone so any duration calculations will work fine.
There is no DATETIME slot type, so you need to handle each slot separately as AMAZON.DATE and AMAZON.TIME. e.g. "Mark completion on {DATE} at {TIME}"
Also, if you are real-world marking completion datetime, can you just generate the timestamp inside your code, rather than making them say it?
Requesting Zip could be a quick way to set timezone, if necessary.
Hacky: If you use Account Linking you may be able to detect their timezone from the client-side on your login page.
Converting between server timetamp and spoken times in the user's timezone will be problematic, but perhaps you can work around it until amazon includes timezone data.
There is a way to find the user's timezone from country code and postal code which Amazon provides. You just need to enable the permission in the developer's console.
After that, whenever you receive a request from Alexa voice service, you will get a consent token. Which indicates that the user has given the permission.
You can then get the timezone of the user by querying Google API. The python code for the same is mentioned below.
# to get the country code and postal code of user
res = requests.get('{0}/v1/devices/{1}/settings/address/countryAndPostalCode'.format(context.System.apiEndpoint, context.System.device.deviceId),
headers = {'Authorization':'Bearer {}'.format(context.System.apiAccessToken)}).json()
postCode = res['postalCode']
countryCode = res['countryCode']
# key specific to the user
apiAccessKey = 'your-api-key'
# Google Geocoding API: provides latitude and longitude from country code and postal code
res = requests.get('https://maps.googleapis.com/maps/api/geocode/json?address={0},{1}&key={2}'
.format(countryCode, postCode, apiAccessKey)).json()
lat = res['results'][0]['geometry']['location']['lat']
lng = res['results'][0]['geometry']['location']['lng']
# Google's Time Zone API: provides timezone from latitude and longitude.
res = requests.get('https://maps.googleapis.com/maps/api/timezone/json?location={0},{1}&timestamp={2}&key={3}'
.format(lat, lng, datetime.datetime.timestamp(datetime.datetime.now()),apiAccessKey)).json()
timezone = res['timeZoneId']

Options for Importing a Database & Displaying a Daily Tip

I am new to iOS programming and looking for advise for an iPhone app that I am creating.
I have an excel database of about 100 daily tips (which will continue to grow) that I want to import into the app, and have one tip display each day. The user will have access to the current daily tip, plus any prior tips from prior days in the database.
I would like to keep it as a closed app, so if a user feels they want to skip ahead to see new tips by changing their current date - I am not worried about the few who might do that.
From my searches so far, CoreData seems to be the way to go but I was looking for suggestions.
Any help is greatly appreciated.
I'll try to give you some advice to achieve what you want.
First of all, what do you mean with
I would like to keep it as a closed app, so if a user feels they want
to skip ahead to see new tips by changing their current date - I am
not worried about the few who might do that.
I'm not sure about its meaning.
Said this, based on my experience (someone else could give you other advice) I suggest you the following.
About your model you need to create an entity, say Tip, that could have the following attributes:
guid: an identifier that works as an identifier, the type could be a NSString
creation date: the creation date for your tip, the type is a NSDate
text to present: the text to present to the user, the type is a NSString
In addition you can also set a title, etc.
The date has two objectives.
First, it allows you to filter tips based on the current date. To filter you need to create a NSFetchRequest and set a NSPredicate. For example:
[NSPredicate perdicateWithFormat:#"creationDate <= %#", currentDate];
In addition it allows to sync with your service to download data. Based on the max date you find in the core data sql lite file, you could ask a service (if you use one) to give you the tips that are greater than that date.
The guid allows to have only one tip for that identifier (you could just use the date for that but I think is easier to have a guid, say 12345). This could be useful if you decide to download each time the whole data and you don't want to insert the same tips. In addition, you don't want to ricreate the db when you have new tips, but you would add only the new ones. So, you need an identifier that let you to verify if a tip is already there.
Finally, about your service (if you want to set up one) you could download data in JSON format. I think it's simply to set up.
If you are interested, here some links that could make your life easier:
Take a look at importing-and-displaying-large-data-sets-in-core-data in the case the data amount of downloaded data is huge. With iOS 5 new APIs are there, but the concepts you find in the post still remain valid.
A simple intro on Core Data (a question I answered in a previous post)
core-data-on-ios-5-tutorial-getting-started
If you want to know something else, let me know.
Hope it helps.

Find timezone from airport code using perl code

As I am right now working on blocking the particular flight to display if the departing time is with in 3 hours of booking time. As, I need to get the timezone of the departing airport to convert it to GMT and thus get the proper difference between the time of booking and departing time of flight. I have searched for many CPAN modules to do the mapping between the airport code and the timezone but I didn't get any proper solution.It will be great if anybody will helpful to me in finding some good solution to it.
I don't know if you will find a CPAN module, but perhaps you can make a converter yourself - it should be simple enough with a small database table mapping airport codes to timezones.
I found the following link containing a CSV file of over 5,000 airport codes and their timezone relative to UTC.
http://openflights.org/data.html
You can import the CSV from that link into your own database and then have your code work around the timezones and airports in that table.

Where is the iPhone's Date & Time getting its time zone list

I can get a list of time zones with [NSTimeZone knownTimeZoneNames], but that only gives the time zone IDs which include one or two cities in each time zone.
The Date & Time settings has a great list of cities and I have seen a few other apps that have the same if not similar lookup lists.
Where do these lists come from?
I do need to relate a picked city to its time zone like Date & Time does.
Only 2? On 3.1 the [NSTimeZone knownTimeZoneNames] returns an array of 401 elements, and there are much less than 200 timezones on the Earth.
I'm pretty sure "other apps" use +knownTimeZoneNames as well, since this is the only public method returning such list. Please make sure your code is correct, though.
Settings.app uses the private CPCity API from the private AppSupport.framework. It does have San Francisco, but it's private.
You need to create your own database (the data can be copied from /System/Library/PrivateFrameworks/AppSupport.framework/all_cities_adj.plist).
What you are asking for is commonly referred to as the Olson database. See for instance this Wikipedia page. The public domain Zone.tab file contains all of the timezones. You can find a zones.tab file in the zoneinfo directory of the libical distribution.
I know it might be a late answer, but just in case someone else stumbles on it like I did the other day. I just open sourced a library that does exactly this. It is available as a CocoaPod and you can find it here:
https://github.com/gligorkot/TimeZonePicker
Also, thanks for all the replies above, they helped me in finding the correct cities database that is used for the Settings app.

passing timezone from client (GWT) to server (Joda Time)

I'm using GWT on the client (browser) and Joda Time on the server. I'd like to perform some DB lookups bounded by the day (i.e. 00:00:00 until 23:59:59) that a request comes in, with the time boundaries based on the user's (i.e. browser) timezone.
So I have the GWT code do a new java.util.Date() to get the time of the request, and send that to the server. Then I use Joda Time like so:
new DateTime(clientDate).toDateMidnight().toDateTime()
The trouble of course is that toDateMidnight(), in the absence of a specified TimeZone, will use the system's (i.e. the server's) TimeZone. I've been trying to find a simple way to pass the TimeZone from the browser to the server without much luck. In GWT I can get the GMT offset with:
DateTimeFormat.getFormat("Z").fmt(new Date())
which results in something like "-0400". But Joda Time's DateTimeZone.forID() wants strings formatted like "America/New_York", or an integer argument of hours and minutes. Of course I can parse "-0400" into -4 hours and 0 minutes, but I'm wondering if there is not a more straightforward way of doing this.
You could use java.util.Date's getTimezoneOffset() method. It's deprecated, but that's pretty usual for Date handling in GWT currently.
And AFAIR, you can specify something similar to "UTC+4" in Joda time.
Update: I looked it up, and it's "+04:00". Or use DateTimeZone.forOffsetHours() or even forOffsetMillis().
Gwittir (http://www.gwtsite.com) is a library for GWT that includes many cool utilities, like databinding, animation, reflection, and more. However, there are some other interesting goodies as well like the new Joda Time integration. If you have ever been frustrated by GWT’s lack of java.util.Calendar support, you’ll love this, as it makes it easy to do date manipulations in your applications.
otherwise, there are other ways to get timezone offset with + & -.
import java.util.TimeZone;
use: TimeZone.getDefault().getRawOffset()
this function will return the offset time in millisecond about your phone seeting. For Example, GMT-04:00 is equals to (-4)*60*60*1000 = -14400000.
After some operations to get the number which you want.
I have a similar but slightly different problem I think.
I actually need to store the clients timezone on the server, so that I can send out messages about dates stored in their calendar.
The dates are stored in UTC time in google app engine and of course I can store the current Timezone offset when creating the appointment. The problem comes when for instance I want to send out a summary email with a list of upcoming appointments in it. These appointments need to be offset with the correct Timezone adjustments for the client (Im happy to assume that they are still in the same timezone as when they created the appointment).
The real problem comes with Daylight Savings adjustments, so for instance I might have appointments stored for Saturday 30th October 2010 at 1pm (BST[GMT+60]) and Monday 1st November 2010 at 1pm (GMT).
So as you can imagine, I cant just use the current timezone offset (BST) as that would mean that the appointment on Monday 1st November would be listed as 2pm rather than 1pm (GMT+60)
It occurs to me that the best way to deal with this is just to store the timezone offset with each appointment individually, but I feel it would be much better to be able to determine the original timezone correctly in the first place, then just let java do the correct adjustments.