The speed zone Here.com SDK I am using to best of my knowledge has school zone data included however when ever I driver through a school zone during school hours (as I am of the view the school zone speed zone is time sensitive) It does not change the speed zone as I expect it would.
Also looking at the SDK schoolZoneSpeedLimitInMetersPerSecond.
It does not make any reference to the zones being time of day and day sensitive.
Does that mean that the school zone alerts operate 24/7 if driving through a school zone even though the school is closed eg outside of school hours and on weekends and school holidays.
The speed limit values for school zones provided by the HERE SDK are sometimes valid based on the current device-time. They are not always time-dependent, and they are notified with the information that is visible on the local road sign.
In your case it seems you see the road sign, but you get no notification. In that case, there may be a data issue and it may be worth to share such places with the HERE team.
Or - it can be that the school zone sign is time-dependent and your device is set to a time outside of that valid time range. Then the notficiation is not forwarded. I am not sure about Waze, but it can be the case that they always forward the limit - even when it is currently not valid, as it's outside the time range.
Related
I built a shopping app using React Native. We have a lot of stores and restaurantes from all over the country registered on our app.
We send messages to our users using FCM when a specific store publishes a new offer, based on user interest and the publisher. If a restaurant posted an offer, we will send to all users registered on the topic "/restaurants". This behavior is bad because maybe the restaurant is too far away from the user, and this offer isn't important to him.
That's why I want to create topics based on a location, so if a restaurant from Chicago posts an offer, I would send just to users registered on "/restaurants/chicago".
Is this the best way to do it? Do firebase offer something similar out-of-box? And how would I keep track of users to know when they go from another city from another?
TL;DR: Text in Bold.
It is possible to create a background service that will (once an hour) get the device location. https://developer.android.com/about/versions/oreo/background-location-limits
Best way to get user GPS location in background in Android
Don't add location background service if you can get away with not having one. It drains the battery.
You should decouple the location from the FCM and use a little bit of prediction. Send a notification when they would start planning to visit the restaurant and resolve their location/group when they open your app.
I assume your app has location permissions enabled. What you should do for your user is store a list of their past locations in the Firebase Database (or the Cloud FireStore). Resolve these locations to a metropolitan area, zipcode, etc. Keep a counter to help weight this location (and to sort)
You should also store a list of restaurants they viewed from a map view...specifically their locations. What you are going to do is compute an approximate distance from a central location and create an average travel time.
E.g. I prefer to eat in a sub metropolitan area that is (on average) 30 minutes from where I live. I also like to eat around 6pm. I need to make a decision about where I want to eat around 5:15pm.
You should also keep track of what times they viewed your app for restaurants in the database To figure out when they start making decisions to eat.
Another concern is the day of the week. For instance, because I live 30 minutes from good places to eat, I will sometimes eat locally. These local places will be packed on certain days of the week.. Thursday they will be packed, Friday will be 1/2 of that, and Saturday is next to nothing. Then Sunday/Monday they pick back up to Friday levels. This is because people are more willing to drive to town on Friday/Saturday night, but they don't want to cook and will eat out on Thursday locally.
Now is when you start using Predictions. Firebase has a Predictions module, and/or you can write Cloud Functions to organize your database and schedule FCM.
First, you need to collect data. One method is to kick off a location service from an hour when they open your app. Hopefully, this will catch your user at which location they chose to eat at (we'll call this the Label, for analytics this will probably be a conversion event). The other trick is to kick off a notification in an hour to rate their dining experience. This doesn't require location background service, and if they open the notification, you can grab their location then.
Having in-App Coupons that the user can present at the restaurant can allow you to grab location.
Also, learn which days of the week they prefer to eat out and which areas they target on those specific days.
If the user is in a different metropolitan area, then waiting until they open the app will allow you to display relevant subscriptions. I flew to Seattle and was starving at 4pm.
Given as many data points (features) as possible (day of week, time of day, day of month, day of 2 weeks, average distance to local restaurants, average distance to metro-restaurants, is_holiday, average_notification_open, average_time_at_restaurant) And data labels (Eat_locally, eat_metro, Eat_home) you should be able to start classifying users into different groups.
So, 1 hour before your user's average eating time, you should perform some server side calculations to determine where your user is likely to eat. For example, if they eat_locally on Thursday night, you should schedule FCM according to the average distance of local restaurants.
Never funnel a specific user to a specific restaurant. Comply with GDPR even if you don't operate in the EU (it covers their citizens). Be transparent with your data collection policy and always try to anonymize/randomize.
I have a Redshift data table where all time values are stored in CST and I convert the time values to the respective timezone based on the zip code (location).
While I do that, I understand that all time values are in Standard time and hence my function usage is
CASE WHEN **** convert_timezone('CST', 'EST', time_column)
WHEN **** convert_timezone('CST', 'MST', time_column)
....
END
This may not be applicable once we enter into Daylight Savings time. How can I take care of this such that I do not modify the SQL query again in 2018 March and in future?
Don't use time zone abbreviations. The are somewhat ambiguous, and can only refer to one aspect of the time zone. Instead, use a full IANA time zone identifier, such as America/Chicago for US Central time.
This is explained well in the Redshift docs:
Using a Time Zone Name
If you specify a time zone using a time zone name, CONVERT_TIMEZONE automatically adjusts for Daylight Saving Time (DST), or any other local seasonal protocol, such as Summer Time, Standard Time, or Winter Time, that is in force for that time zone during the date and time specified by 'timestamp'. For example, 'Europe/London' represents UTC in the winter and UTC+1 in the summer.
As far as the "...based on the zip code" part of your question, understand that not every ZIP code is locality-based. There are also technical assignments, overseas APO/FPO addresses, US territories, and other edge cases. Additionally, some zip codes may straddle more than one time zone.
A better approach, when possible, is to:
Get an approximation of latitude/longitude coordinates - using a variety of techniques depending on your source data. For example, geocoding APIs can take a street address and give a lat/lon.
Then determine the time zone identifier for that location, using one of the techniques listed here.
We have a database of cities with its geo coordinates. Once we filled it with corresponding time zones using tzworld. User sets location including city, city has time zone - here how we know user's timezone (we need to render date and time on server). But time zones are being changed: some new are appearing, some old are being removed.
Is there any best practices or tools to handle that kind of changes?
I.e. there is a city Foo with time zone Foo/Bar. One day tzdata was changed, and Foo/Bar was split into Foo/Old_Bar and Foo/New_Bar time zones with the same UTC offsets. We still have Foo/Bar in our db. Actually, it's a BC break, but it's ok since, say, we can handle those BC breaks. But then tzdata was changed again, and now Foo/New_Bar has different offset. And here comes troubles. Some users from Foo city see wrong local time since that moment.
Just to be sure you understand me right: it's not about DST, it's about the fact that time zones (their names) are being changed.
As far as I can see, wee need a kind of machine-readable tzdata diff. Like
split: Foo/Bar Foo/Old_Bar,Foo/New_Bar
move: Foo/New_Bar -05:00
This issue makes me feel that storing time zones is a bad idea. Is there a better one?
With specific regard to the IANA/Olson TZ database, the location identifiers do not change once established. The history of each identifier is always consistent for that location.
However, if you are using tz_world or some other map source to determine the time zone for some other location - one that doesn't necessarily have it's own identifier, then yes - it's possible that a zone split will cause the zone to change. Though, when it does, the new zone should be consistent with the old zone, up to the point of the change.
As a real world example, consider America/Fort_Nelson, which was added in tzdb 2015g for Fort Nelson, British Columbia, Canada, and the surrounding region of the Northern Rockies Regional Municipality. Previously, this area would have been resolved to America/Vancouver, but the zone was split due to their March 2015 time change. The tz_world maps were updated on November 7, 2015 to account for this change.
If you had previously resolved a user in Fort Nelson to America/Vancouver, then they will have incorrect times from November 1st, 2015 forward, as that's when Vancouver switched back to UTC-8, while Fort Nelson remained at UTC-7.
If you update to the latest tzdb and tz_world, you can use the original information to re-determine the time zone - which would now be America/Fort_Nelson.
The new time zone will accurately reflect all of the same information as Vancouver before the split, and the correct information for Fort Nelson after the split.
All of this should just work, assuming you update time zones after each update of tz_world, and recalculate future events after updating the tzdb.
The question remains, how do you know which zones have split and changed so you don't have to recalculate everything? For a small amount of data, you might as well recalculate everything. But for larger datasets, this might be impractical. Unfortunately, there's no machine-readable standardized format for the differences. I believe this has been talked about before in the tz discussion list, but I can't find it at the moment. You can ask there if you like.
Currently the only way is to manually read the release notes of each update. You can find them in the tz-announce list archives (or subscribe to the list for future updates). You can also find them in the NEWS file of any given release. You'll also want to review the history of the tz_world shapefile, which is on that web site.
Also, recognize that time zone IDs will never be removed from the tzdb. A split may create a new zone (Foo/New_Bar), but the original zone will remain (Foo/Bar, not Foo/Old_Bar). If a zone is determined unnecessary, its Zone entry might be replaced with a Link entry, but it will never be removed entirely.
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.
I want to know if there can be 2 or more GMT timezones for one city or state. I know there can be more then one GMT timezone for a country, but not sure if it's for state and city too. Share your knowledge please.
Interpreting the question to mean 'are there any cities which are in more than one time zone', then the answer is 'yes'. And there are American states with multiple time zones (Indiana and Arizona being two of them).
There has been recent discussion on the TZ mailing list about the area of China known as Xinjiang, which has a mixed population of Han Chinese and of Uyghurs. It seems that the Han use the standard Chinese time zone (Asia/Beijing), but the Uyghurs often use a local time zone. This is now encapsulated in the Olson database, with the name Asia/Urumqi for the Uyghur time zone.
So, for example, the zone.tab file in tzdata2010b.tar.gz, available from ftp://elsie.nci.nih.gov/pub/tzdata2010b.tar.gz (the code is ftp://elsie.nci.nih.gov/pub/tzcode2009t.tar.gz). There is an extensive description of how and why the change was made in the asia file.
Note that the Olson (Time Zone) database is now (2016-09-19) available from IANA at https://www.iana.org/time-zones rather than from NIH. You can get the current release easily enough; getting historical releases may be harder.
Yes, time zones really do change 20 times a year around the world, and sometimes at essentially no notice (that is, the government legislates the changes only a day or two before the change).
#basit asks:
Wow about the 20 times a year around the world. I'm trying to log the timezone for latitude and longitude, so now my question would be, how long should I log the data for? 6 months? 1 month? 2.. 3..?
And also, how long does it take for daylight savings to change in a year, because I need to log timezone with daylight saving and refresh the data after certain given period.
What I mean is that during the course of 2009, there were 20 issues of the time zone database, because of changes in rules in at least that many places. However, any given country usually only changes their rules once - though with Argentina, different states were changing their rules at different times and compounding the problems.
I'm not clear that we have enough information to tell you how long to log the data for. I'd be inclined to say at least 12 months, but it depends what you are going to do with it. At one level, all you need to do is keep up with the Olson database - that will tell you the time zone rules for essentially everywhere in the world. If you are interested in tracking the time zones of your visitors, then you can keep the data for as long as you like. Since not everyone uses the canonical Continent/City notation for their time zone (I tend to use the older US/Pacific notation, for instance - which is still supported, but is equivalent to America/Los_Angeles). The classical notations such as TZ=EST5EDT are ambiguous; both the USA and Australia have timezones that use EST as an abbreviation, and the dates when the switch between standard and daylight saving time occurs varies (witness the mass of data in the Olson database).
You also ask 'how long does it take for a time zone to change'. I'm not sure what you mean. In terms of 'when the clocks change (between standard and daylight saving time)', it is 'instantaneous'; one second it is one time zone offset; the next second it is the other. If you mean 'how long does it take for governments to change their mind', it varies radically. For example, both Europe and the USA have relatively fixed rules that change every few years; the rule in the USA had been stable for about 20 years, then they changed the rules about 3 years ago. Europe is similar. On the other hand, some countries change their rules yearly. My impression is that some of the Islamic countries adjust when they switch between standard and daylight saving time (or vice versa) depending in part on when Ramadan falls - if the change would occur during Ramadan, then they bring it forward, or delay it, so that the rule does not change during Ramadan. Other countries have different reasons for the brinksmanship that goes on - maybe it is the political equivalent of a release deadline. So it may take quite a while for people to decide what the 'final' (meaning 'next edition') of the rules will be for a given year.
The web site http://worldtimezone.com/ does a pretty good job of keeping track of most of these idiosyncracies.
I think you mean "Can one city or state span two time zones?". Yes. Mexico Beach, FL sits on the border between CST and EST with parts of the town in both time zones.
As for how you could tell a computer that, no idea.
There is only one gmt for the whole world. As for timezones, see here, showing variation of observance e.g. within Kansas.
Any arbitrary jurisdiction may have multiple timezones, though the majority do not.
Have a look at http://www.worldtimezone.com/faq.html