Hi I am very new to Android Development. I want to pick the country name based on the current time of the particular mobile, while clicking the button. How can i do it? Any body tell me? Thanks in advance.
It seems difficult considering most timezones contain multiple countries (and countries multiple timezones as well).
See: Android: Is there a way to get timezone for Country name?
Per above, the closest you'll get comes from here:
For getting the time zone, check out the "O" and "T" format specifiers
of the date() function. "O" will give you the Difference to Greenwich
time (GMT) in hours (your time zone offset) and "T" will give you the
time zone abbreviation like "EST" for Eastern Standard Time.
e.g. <?php echo date("T"); ?> will give you the executing PHP script timezone, for the user timezome you can pass their date/time as the second argument.
I don't think thats possible because you can have MANY MANY countries on the same time. For example, just take the GMT+/-0 time zone, you'll have England, France, Spain, Portugal, and a few others you can get from the african countries. You can't do it like that.
What i'd suggest is to implement a GEOIP location using for example: MaxMind GEOIP. You have some very powerful tools available in PEAR for that and it took me about 4 hours to setup the library, understand the code and do the code to query. I was querying for IPs and countries and even states/provinces in less than 4 hours. You can't get faster than that unless your a genious :)
Related
I am looking for the most simple and cleanest way to fix the timezone for all dates in an Android app. The idea is to have the app running as if the user were in another timezone. Let me clarify what I am looking for:
Let's say the user's phone is set to America/New_York then I would like my app to show all dates (are in UTC) in the Europe/Amsterdam timezone, regardless of the timezone that is set on the phone itself. And if I make a comparison with a new Date() it would be very nice if that new Date() is also in the current time of the Europe/Amsterdam timezone.
After searching the internet for solutions, I started to get the feeling that I will have to update every place in my app where a Date is used and force the use of the target timezone, like the solution of this stackoverflow post: Converting UTC dates to other timezones
Does anybody know how to get this done in a more easy and cleaner way?
The answer for anyone using java.time, the modern Java date and time API.
java.time does not include an option for setting the JVM default time zone. And wisely so. It’s not something you should want to do. By doing it you affect every program running in the same JVM, and also every part of your program and other program in the JVM may set it differently, ruining your intentions.
Avoid the need
In your time operations be explicit about which time zone you want, and you will always know what you get independently of the JVM setting. Example:
System.out.println(ZonedDateTime.now(ZoneId.of("Asia/Dushanbe")));
Example output:
2021-05-09T00:36:25.171213+05:00[Asia/Dushanbe]
System.setProperty
If you have already written a lot of code relying on the default time zone of the JVM, the hack to set it is:
System.setProperty("user.timezone", "Australia/Tasmania");
System.out.println(ZonedDateTime.now());
This just printed:
2021-05-09T05:38:03.568350+10:00[Australia/Tasmania]
It’s not very robust, though, for the reasons mentioned in the beginning.
If you want validation of the string you are passing, use:
System.setProperty("user.timezone", ZoneId.of("Australia/Tasmania").getId());
Disclaimer
It seems from your question that you are already using the old, poorly designed and long outdated java.util.Date class and friends. I still wanted to post the answer for users who have the option to go modern. (You may also use each of the two ideas presented with the out-dated API.)
I would try TimeZone.setDefault(TimeZone) like in:
TimeZone.setDefault(TimeZone.getTimeZone("Europe/Amsterdam"));
(advice to check returned time zone, getTimeZone does not throw exception for unknown time zone - or use ZoneId instead of the String)
see TimeZone (this also mentions the user.timezone system property)
but I am not an android programmer/user
When using Magnolia CMS' DateFieldDefinition class: if my computer's current date is not matching the saved date's Daylight saving time, the saved date's time will be incorrect.
The relevant class: info.magnolia.ui.form.field.definition.DateFieldDefinition.
The relevant Vaadin component "Date and Time Input with DateField".
Another person seemed to have the same problem.
EDIT: Magnolia CMS appears to have a ticket about this issue already
Example:
In this example, I am running Magnolia CMS locally.
My computer's current date is Oct 17th, 2016
My computer's TimeZone is "Switzerland/Zurich"; hence I am on GMT+2 for the current date (summer time for my time zone)
In Magnolia Admin Panel, I save a date on Nov 3rd, 2016, hence that date is in winter time for my time zone, so GMT+1
That's where it gets interesting:
I change my computer's date to Nov 2nd, 2016, hence I am on GMT+1 (winter time for my time zone)
In Magnolia Admin Panel I open that date, it shows one-hour less.
Illustrations
The date/time implementation in Magnolia 5 was (and possibly still is) rather bad because of several issues:
It failed to distinguish between points in time (e.g. Skype appointment with someone possibly in another time zone) and "concept" times (e.g. a note when to make breakfast - it will always be at 7:00, no matter what time zone, so it's not about a specific point in time but about the concept of 7 o'clock)
It saved dates as timestamps although dates are neither timestamps nor time spans. This inaccuracy lead to the next problem:
Since dates were treated as timestamps by Magnolia 5 and timestamps were always handled as "points in time" by Magnolia 5, dates were also treated as points in time by Magnolia 5 although this is always wrong. Dates are always just "concepts" (in above sense), e.g. dates of birth. If I'm born on 1st January 1980, then that's my date of birth, and that is so in every time zone. My date of birth is not 31st December 1979 in another timezone, like it would with the "point in time" semantics mentioned earlier.
Dates and times were saved as instances of Calendar in JCR, that is a timestamp with a timezone. When transferring data from one Magnolia instance to another (Export, Import, Activation), the actual timestamps were copied as they were, they were not converted to the timezone of the target system. This meant that when the target system finally read the values, it may have seen wrong dates and/or times unless it explicitly converted the values.
Magnolia used to use the Browser's time zone for reading dates/times from the user by the Vaadin date/time fields but the server time zone for storing them in JCR. This meant there was always an implicit translation that may or may not have been wanted in the business logic. In many cases wrong values would end up in the repository (e.g. when entering dates of birth), so the later processing based on them had a certain probability of going wrong. In any case it had to be expected that the date/time saved in the repository was not the one the user had entered.
In a support ticket I wrote to Magnolia about these isuees they said they had fixed it in Magnolia CORE 5.4.11, which will be available since 5.5.1. I haven't tested these fixes yet, but unless you use this fixed version I wouldn't recommend to expect a simple solution for your problem, which comes on top of the problems I mentioned above. I did so just to document how little room there is to get the correct behavior for your use case with provided classes unless you needed exactly the use case they had implemented.
I'm trying to write a world clock app that returns the sunrise and sunset information for a given time zone. The thinking is that the user will either specify the GMT offset or give the time zone explicitly. Then the application will look up the latitude and longitude using the java.util.TimeZone found (or possibly given the GMT offset). I realize the time zones are usually not a very accurate way to get geolocation information since they are mostly based on political borders, but it seems like something like this exists. Most of the sites/apis I've find will give the timezone for the latitude and longitude, but I want to do a reverse search (return latitude and longitude for the given time zone). Thanks in advance for your help.
Let me show you the level of error you can expect if you do this to my home country, New Zealand, which is in one time zone (excepting remote islands), yet stretches over a large range of latitudes:
Invercargill, New Zealand
Time zone: NZST
Sunrise today: 7:05 am
Auckland, New Zealand
Time zone: NZST
Sunrise today: 6:34 am
Expect similar problems with China (the whole country is one timezone), Chile, Argentina, and others.
Nice idea, but probably unworkable.
Geonames.org has a downloadable database of towns that includes all kinds of information, including timezone and population. You could use it to populate a database that maps from timezone to the location of the largest city in that timezone.
Note that GMT offsets are very useless for this purpose, but fortunately the continent/city terminology of timezone IDs makes it very easy for users to choose the correct one.
Time zone is an area, so you would have to return coordinates of the border of this area (and probably add some method to check given point is inside). So you have to starts with geo data. Keep in mind that lot of countries have summer time so the time zones are not constant.
After reading everyone's answer, I think I'll probably use Google's Geocoding API, which returns the latitude/longitude and timezone for a given physical address. I'd just have to add an interface that lets the user enter an address, city or post code in order to retrieve the info from the api and calculate the sunrise/sunset times. This is better than trying to store all this information locally in a database (which would be huge). Thanks to all who answered.
Trying to get a time stored in a datadase.
select dbtimezone from dual gives me -07:00
I am using Java program to get the Date from Oracle
Column i type of Date.
while i am fetching the time in my java program am getting it as GMT.
actually i want the time as it is there in database not converted time.
Though i can convert back to -07:00 , i am seeking another way to do because conversion always depends on the dbtimezone of the database using.
Can any one help me ?
Thanks in advance
That oracle just has one timezone can make life difficult if you deal with different timezones. I've always thought life was easier if you consider timezone a view artifact and
represent all times as UTC, then convert in the view. You put the timezone information someplace in the database and convert accordingly.
...actually getting that right can get interesting because you don't want to make the same mistake of being too general again. For example, a client may be based in a particular timezone, but have offices in many. Though an office is in a particular timezone, the activity relating to the time may involve a different timezone etc.
See java.util.TimeZone, more specifically the getOffset methods, which return the number of milliseconds to add to the UTC time to get local time. Note that it also considers the daylight saving time.
Below is a snippet of the list of timezones returned from java (I've printed the timezone offset, timezone ID, and long name, using JodaTime).
(GMT-10:00) HST, Hawaii Standard Time
(GMT-10:00) Pacific/Apia, -10:00
(GMT-10:00) Pacific/Fakaofo, Tokelau Time
(GMT-10:00) Pacific/Honolulu, Hawaii Standard Time
(GMT-10:00) Pacific/Johnston, Hawaii Standard Time
What is the difference between HST, Pacific/Honolulu, and Pacific/Johnston, for example? They all seem to use Hawaii Standard Time, why are there 3 entries in the database?
My ultimate goal is to just create a list of timezones for user preferences in a web app.
If I use all of the timezones from the tzDatabase the list is long and appears to have effective duplicates (example above). I could just list unique long-form-names such as "Hawaii Standard Time", but then I need to decide how to map it to any one of the timezones that use that same long name.
What do other people do in this case? How do you create a nice user-friendly list of timezones and map them to their relevant java TimeZone?
I think you are making the assumption that "user-friendly" means to show them a small list. The fact is though that all of those time zones are used by someone, somewhere. They may look the same to you but they often have slightly different behaviour. I live in Saskatchewan and we have our own version of CST. The long name is only "Central Standard Time" but we don't use DST so for half of the year, we don't line up with real CST. There is even one small area of Saskatchewan which has a 15 min difference in the time. Even if they seem the same, they are different and I think you should allow the users to select from the whole list.
Trying to intelligently shorten the list might be comparable to not listing all possible currency codes when allowing a user to select a preferred currency. Yes, there may only be a handful of people who use certain ones. Sure, there may be some with the same conversion rates currently. In the end, let the user decide what they care about.
One solution for showing large lists or potentially un-important data with only a few items of real interest: Determine the commonly used ones first and then separate them to the top of the list. This can be seen on various websites for selecting Country, for example:
Canada
United States
------------------
Argentina
Australia
...
This strategy is also often used for my previous example of currency. It could look something like this for time-zones (If your main user base is in North America):
EST
CST
MST
PST
------------------
Hawaii
Saskatchewan
...
Remember though, this will require you to manually, pre-determine what the common time zones are.
I feel the best approach is to simply list all timezones, sorted by offset because most people will know where to find there zone based on offset. For instance, I always look first for "-6:00", not Saskatchewan. Hope this helps!
The CLDR data contains a list of "important" time-zones and can probably be used to pick the ones to display. (I remember something else, but this is the best I can find now)
Multiple time zone ids will exist for the same place if the data was different in the past, or if the place has been renamed (the alias feature in the time-zone data). Removing the backward file when compiling the time-zone data would remove most aliases.
Whether or not the timezone uses daylight savings time is probably the most common difference.