I am currently creating application which requires Current Time From the Country.
I have latitude and longitude of different Country.
I have use following Link to get the Current Time
http://api.geonames.org/timezone?lat=21.7679&lng=78.8718&username=demo
(demo user name is by default and used only for testing because it has query limit)
I got the current Time but when Daylight Saving Time is ON. Is that API gives me the correct Time? If not then how could i get the current Time.
In some of the API I get the current time like earthtool(not implemented DST). But i could not Test because currently there is no DST Implemented so how can i test in this case?
I am Creating Application in .NET with C# 4.0
If any other API then please Tell Me but first priority to GeoNames API.
I would be very surprised if that didn't reflect the current local time. The results for Sao Paolo (which is currently observing DST) seem to agree with that:
<geonames>
<timezone tzversion="tzdata2012f">
<countryCode>BR</countryCode>
<countryName>Brazil</countryName>
<lat>-23.0</lat>
<lng>-46.0</lng>
<timezoneId>America/Sao_Paulo</timezoneId>
<dstOffset>-3.0</dstOffset>
<gmtOffset>-2.0</gmtOffset>
<rawOffset>-3.0</rawOffset>
<time>2012-12-17 10:48</time>
<sunrise>2012-12-17 06:14</sunrise>
<sunset>2012-12-17 19:47</sunset>
</timezone>
</geonames>
However, another alternative would be to use the GeoNames API to get the time zone ID, and then use Noda Time for everything to do with that time zone. (Disclaimer: I'm the primary developer of Noda Time.)
You can't just use the BCL's TimeZoneInfo class directly, as that doesn't support TZDB the time zone IDs that GeoNames provides (e.g. "Asia/Kolkata"). You could just use a mapping (CLDR provides one) but in my experience the Windows time zone information has some disturbing oddities.
If you just need to know the current time, GeoNames is probably fine -
Related
I have searched the questions here and gone through a fair amount of the API. I have not found reference to requesting historic route data. My questions is this; Does the Here api support historical route data. An example request would be that I seek the mileage from point a to point b 365 days ago, when perhaps a key route obstruction existed such as a bridge was out or a road was closed for construction that resulted in more miles during that historic period.
I would like to answer this in two parts
Can a route be calculated for a past date ?
Yes, you can. You need to request a Time Aware Route like below. You can read more about it in the developer site.
`
GET https://route.api.here.com/routing/7.2/calculateroute.json
?app_id={YOUR_APP_ID}
&app_code={YOUR_APP_CODE}
&mode=fastest;car;
&waypoint0=geo!37.743385,-122.422835
&waypoint1=geo!37.743878,-122.423686
&departure=2014-03-12T10:00:00
&routeattributes=sh,bb,g
`
Will the map used for the query depend on the departure date ?
No, Here API always uses the current version of the map available unless you specify explicitly the map version. But you can specify only till previous two releases.
So for your question, you wont be able to get the map data for a past year even using map version. But what you can do, is explicitly avoid the bridge or road newly constructed so that the api doesn't suggest that route. You can do this through Custom Route Extension API like below example.
GET http://cre.api.here.com/2/overlays/upload.json
?map_name=OVERLAYBLOCKROAD
&overlay_spec=[{"op":"override","shape":[[50.10765,8.68774],[50.10914,8.68771]],"layer":"LINK_ATTRIBUTE_FCN","data":{"VEHICLE_TYPES":"0"}}]
&storage=readonly
&app_id={YOUR_APP_ID}
&app_code={YOUR_APP_CODE}
I have web application which controls the stores locate din different time zones.
In this web application user will set rules that, any particular product is in discount for any given period of time i.e. 1-Aug 2014 to 5-Aug-2014. so how can this rule be executed in web application. this info can be inserted from anytime zone. but store in Europe and Store in US should have to make this product available from exact 1-Aug-2014, Europe will be early compare to US.
SO how we can handle this kind of scenarios.
In general:
Store the time zone for each store, such as America/Los_Angeles or Europe/London.
When checking for discounts, get the current UTC time and use the store's time zone to determine the appropriate local time.
Compare that local time against the expiration date for the discount.
This assumes that the business rule is to rely upon the store location's time zone. This might not necessarily be the case - as many online stores serve customers worldwide without regard to where the physical store or product is located. In that case, you need to determine who's time zone is applicable. Is it a single fixed time zone for the whole company? Or perhaps it's aligned the end-user's time zone, such that those in different time zones would have the offer expire at different times. You'll need to decide what is appropriate for your particular business.
Sorry I can't be more specific, but you didn't provide many details to go on. If you need further assistance, please consider editing your question to include details such as what language and platform you're using, what code you have tried, and what the specific business rules are.
When getting information from Twitter's API for a user, they provide two fields related to the user's time zone:
utc_offset: -14400,
time_zone: "Indiana (East)"
Unfortunately, this doesn't tell the full story because I don't know if that UTC offset was calculated during standard time or daylight savings time. After dividing by 3600 seconds, I get -4 hours, which is valid during the summer months, but in the winter the correct value would be -5 hours.
If the value was ALWAYS determined by the daylight savings time value then I could write an algorithm for that, however after some searching on the subject I've seen several pasted outputs that contradict that assumption. (as a quick example, this question shows his/her offset as -21600 and then he/she says he/she is on central time, which if calculated during daylight savings time would be -18000).
It would make sense to me that the value would be calculated as of Jan 1 and the several pasted outputs I've found online fall into that category, but my own Twitter account shows the values listed above for which this assumption is invalid. My next thought was maybe it was calculated at the time I created my account, but then that seems erroneous as well because I can change my time zone at any later point (and even so, I created my account in November when I would have been on standard and not daylight time!).
My last thought was that maybe the value is being calculated by the date of the API request. This makes a lot of sense and the Twitter accounts I own all seem to validate this. BUT, the SA question I linked to earlier shows that the person answered the question on June 2nd, which is daylight savings time and his/her value of -21600 reflects a standard time for the Central time zone.
Anyone out there solve this problem? Thanks so much!
Twitter's front end uses Ruby on Rails. If you go to your own twitter account settings and look at the possible options for time zones (view source on the dropdown list), you will find that they match up with those provided by ActiveSupport::TimeZone, shown in this documentation. Although there appears to be some zones understood by Rails that Twitter has omitted, all of the Twitter zone key names are in that list.
I have asked Twitter to use standard time zone names in the future, in this developer request.
Why does Rails limit this list and use their own key values? Who knows. I have asked before, and gotten very little response. Read here.
But you can certainly use their mapping dictionary to turn the time_zone value into a standard IANA time zone identifier. For example:
"Indiana (East)" => "America/Indiana/Indianapolis"
"Central Time (US & Canada)" => "America/Chicago"
This can be found in the Rails documentation, and in the source code. (Scroll down to MAPPING.)
Then you can use any standard IANA/Olson/TZDB implementation you wish. They exist for just about every language and platform. For further details, see the timezone tag wiki. If you need help with a specific implementation, you'll need to expand your question to tell us what language you are using and what you have tried so far. (Or consider asking a new question about just that part of it.)
In regards to the utc_offset field, twitter does not make it clear what basis they use to calculate it. My guess is that it is the user's current offset, based on the time that you call the API.
Update 1
I have added support for converting Rails time zone names to both IANA and Windows standard time zone identifiers in my TimeZoneConverter library for .NET. If you are using .NET, you can use this library to simplify your conversions and stay on top of updates more easily.
Update 2
Twitter's API now returns the time zone in this format:
"time_zone": {
"name": "Pacific Time (US & Canada)",
"tzinfo_name": "America/Los_Angeles",
"utc_offset": -28800
},
Use the tzinfo_name field. Done. :)
Here's a screenshot of my twitter feed (as of right now while me writing this Question).
Notice how the time is relative to me, right now? (those times differences are correct, btw)
How do they calculate that?
The reason I ask is that right now, i'm in Melbourne Australia. When I Remote Desktop to a server in the states, log in to twitter (using the SAME account) .. i get the same results!
At first, I thought they were calculating this based upon my account settings for Time Zone (which btw is set at +10 GMT)
But if that was the case, when I remote desktop to the server (which is in San Fran, CA) it should be showing different results in that RD terminal, right?
So how could they have coded this, please?
Twitter more than likely stores the date it was posted in UTC, it knows the time now in UTC (both on your machine and on the server).
Given that those date times are translated into the same timezone (UTC), it's a simple matter of taking the difference between the two times.
It's the same thing the Stack Exchange sites do to stamp the times for all the activities that you see.
As long as you're able to convert any representation of date time to UTC (which pretty much every API in existence has), this value is able to be computed as Twitter will push the UTC time down to the clients which then do the math (or do it on the server and pass the differences down); the settings that you see for UTC offset are when absolute times are displayed to you and you want them relative to your timezone.
I am trying to determine, how I should implement local time in a web-app. All users are logged in, there are no anonymous users. They will need to see all time-values in their local time.
Is this how it should be done?
All DateTime values are saved as UTC-time in database
Each user has a UTC-Offset value stored in his profile
When displaying a datetime-value, I take the value from the database, and apply the users offset.
Is this the way to go? Or am I missing something?
Don't store a UTC offset for the user - that's not enough to know the full time zone information. You should store their Olson time zone ID, e.g. "Europe/London". Then you can display any UTC time in the local time, taking into account historical changes, daylight savings etc.
EDIT: It looks like the TimeZoneInfo ID isn't actually in the normal Olson format - but so long as there's something sensible you can display to the user (as a choice), and an ID you can retrieve the zone from later on, that's probably okay... you may have difficulties if you need to interoperate with other systems later though.
You should ask the user for their time zone (possibly trying to guess it first through JavaScript) - they will have more information than you do.
You should investigate the TimeZoneInfo class for more on this - I can't say I've used it much myself, but it's the way to go as of .NET 3.5. In particular, FindSystemTimeZoneById and GetSystemTimeZones will be important.
Time zones are a pain in general, but at least TimeZoneInfo gives a lot more support than the old TimeZone type.
That sounds like the most straightforward way to me. The only slip ups I could see occurring are some areas (such as parts of Indiana and I think all of Arizona) don't cooperate with daylight savings time, so you'll have to take extra precautions displaying the correct time for them.