I am developing an Android app for an Ethiopian company and have to deal with dates.
The calendar used in Ethiopia is similar to the Gregorian one but has two main differences: it's set approx. 7 years earlier and has 13 months.
At the time I post this question the date is 13-09-2021 in the Gregorian calendar and 03-01-2014 in the Ethiopian one.
My questions are:
does Android support the Ethiopian calendar and is it customary for people in Ethiopia to have their devices use it?
if so, do I have to get the default formatter (that uses the default calendar: Calendar.getInstance()) in order to format the date properly?
instead, if the device uses the Gregorian calendar how does Java support the translation to the Ethiopian date?
What would you suggest in order to simulate the full scenario, with the device set with the proper current Ethiopian date (as if coming from the network provider) and locale?
While I know nothing about these calendaring systems, perhaps…
ThreeTen-Extra
Add the ThreeTen-Extra library to your project to access the EthiopicChronology class that plugs into the java.time framework bundled with Android.
This chronology defines the rules of the Ethiopic calendar system. This calendar system is primarily used in Ethiopia. Dates are aligned such that 0001-01-01 (Ethiopic) is 0284-08-29 (ISO).
You can also find a CopticChronology class there too.
About the calendrical background:
The Ethiopian calendar is rather a local calendar with some popularity in Ethiopia itself. And yes, there is even a special time keeping mode in this country starting the day at 6 am. However, I am not sure if the calendar is also wide-spread on mobile phones due to lack of sufficient support in the common operating systems like Android, IOS or Windows. Outside of Ethiopia, it is probably only relevant for religous minded Ethiopian people in the diaspora.
Support on Android:
You can find some support presented by the class EthiopicCalendar delivered by IBM. I strongly assume that Amharic numbers are supported (but am not completely sure). I am less confident about the support for 6 am as start of the day and counting as zero (relevant if you ask for the current date). IBM says (similar but not identical to the standard usage of Calendar.getInstance()):
EthiopicCalendar usually should be instantiated using
Calendar.getInstance(ULocale) passing in a ULocale with the tag
"#calendar=ethiopic".
The API of IBM offers a translation to the gregorian calendar and vice versa via the counted milliseconds since 1970-01-01T00:00Z. For formatting or parsing, use the dedicated formatter engine of IBM. Attention, it is not the standard formatting engine of Android. Of course, you have still to worry with strange features like counting the first month as number zero (instead of one).
Alternative library Time4A:
My library Time4A is also written for Android and is a sister project of the main lib Time4J. Both libs contain the classes EthiopianCalendar and EthiopianTime. You will find some code examples in the javadoc. Support for non-decimal Amharic numbers exists, too. These classes require a special formatting engine, too, called ChronoFormatter. Like in case of IBM, Ethiopian month names like Meskerem (even in Amharic or other languages) are well supported.
A transformation to the gregorian calendar (and vice versa) can be obtained by the expression ethiopianDate.transform(PlainDate.axis()) where the parameter denotes the target calendar (here, PlainDate is the gregorian type).
Related
I am using android.text.format.Dateformat package. For same locale, I am getting two different date formats. For example, US - 7/21/2017 and in another device as 7/21/17. First device is with API 18 and second one is API 24.
Different JRE implementations can have variations in how classes are implemented, even across versions. Your two devices likely have small variations in the default US date format, as in 2 vs 4 digits years.
You need to provide some code and JRE details if you want further guidance.
android.text.format.Dateformat will print strings that take into account the preferences set in the user's settings app. Almost every phone will allow you to choose between 12-hour and 24-hour time (e.g. 3:00 PM vs 15:00), but some phones also allow you to choose the format you'd like to see dates in.
I suspect your first phone's setting is M/d/yyyy and your second phone's is M/d/yy.
I'm trying to make an activity where I can select a time and date to save in a database to later use on a calendar to highlight days that are saved in the database. I looked into the DatePicker and TimePicker but unfortunately it tells me that i would need api 24 to use a lot of the functions i would need. Is there another option to select a date and time? Or are there functions i can use from the Calendar that are available for api 16?
In a few cases, there are multiple classes with the same name in the Android SDK:
java.util.Calendar vs. android.icu.util.Calendar
android.app.Fragment vs. android.support.v4.app.Fragment
java.security.cert.Certificate vs. javax.security.cert.Certificate
And so on
When adding the import statement to your project, pay close attention to which one of the duplicates that you import, so you are using the one that you expect.
In your case, you want java.util.Calendar, most likely.
I am looking for solution, how to deal with the data which has specific time related data.
Project Architecture :
Backend is RESTful services build in Java.
Frontend is:
1. Angular JS (for web only)
2. Native Mobile App (Android, iPhone).
For eg. one device is in UK (i.e. UTC+1:00) time zone another device is
in HKT (Hong Kong i.e. UTC+8:00) timezone.
My server is in Germany (i.e. UTC +2:30) timezone.
What I should keep at server?
How to show current time at each device (web browser as well as mobile devices), and if I am serving web pages, which can be accessible from anywhere, which timezone value I should keep?
Current solution:
Currently I am keeping whenever data is arrived at server calculate the UTC epoch time and store it, send the time as it is via REST and then at client side (web browser or Android device ) I am converting it to local Timezone.
Is this approach correct?
Yes, your approach seems fine and correct.
For your implementation: if you're using Java 8, consider using the new java.time API. It's easier, less bugged and less error-prone than the old APIs.
If you're using Java <= 7, you can use the ThreeTen Backport, a great backport for Java 8's new date/time classes. And for Android, there's the ThreeTenABP (more on how to use it here).
The code below works for both. The only difference is the package names (in Java 8 is java.time and in ThreeTen Backport is org.threeten.bp), but the classes and methods names are the same.
To get the UTC time, you can use the Instant class. It's the best choice because it's always in UTC, and can be easily converted to and from another timezones:
// get current UTC time - Instant is always in UTC
Instant instant = Instant.now();
// you can use the string representation
System.out.println(instant.toString());// 2017-06-06T11:57:21.665Z
// or the timestamp (epoch millis - milliseconds from 1970-01-01T00:00:00Z)
System.out.println(instant.toEpochMilli());// 1496750241665
// convert to another timezone (always use valid IDs)
ZonedDateTime z = instant.atZone(ZoneId.of("America/Sao_Paulo"));
System.out.println(z);// 2017-06-06T08:57:21.665-03:00[America/Sao_Paulo]
// in another timezone
z = instant.atZone(ZoneId.of("Europe/Berlin"));
System.out.println(z);// 2017-06-06T13:57:21.665+02:00[Europe/Berlin]
// convert back to UTC Instant
System.out.println(z.toInstant()); // 2017-06-06T11:57:21.665Z
The API uses IANA timezones names (always in the format Continent/City, like America/Sao_Paulo or Europe/Berlin). Avoid using the 3-letter abbreviations (like CST or PST) because they are ambiguous and not standard. You can use ZoneId.getAvailableZoneIds() to get a full list of all timezones names.
You can also use ZoneId.systemDefault() to get the system's default timezone. In this case, if the code runs on a server, it'll use the server's machine timezone. And if it runs in a device, it'll use whatever is configured in the device.
Tapestry comes with Date picker, which is fine if you want to pick dates only.
However, I'm in need of selecting time as well (date and time filtering).
Due to specific reason, I am not allowed to use jQuery, which is unforutunate, because I've found this neat Date and Time picker: https://fgelinas.com/code/timepicker/
Is there a similar, but Prototype based Date and Time picker for Tapestry 5.3?
Take a look at Howard's tapx-datefield library. I've not used it myself but it claims to support date & time. I think it wasn't included in tapestry core because of license incompatability.
I have a gregorian calendar that serializes to the string below during a soap request
2079-07-07T00:00:00.000-07:00
The .NET webservice reads it as the string below
07/07/2079 01:00:00
Is the 07:00 causing the issue? If so how can I get rid of this?
Someone might be able to give you an affirmative answer if you tell us which time zone is configured on your system, but I would assume a mismatch in the DST rules.
The JVM comes with its own timezone and DST rule database, while Windows (and .NET) uses a different database. In theory, the two databases should of course contain the same rules, but I have ran into differences in the DST rules for historical dates. I would assume there might be differences for dates far in the future as well.
If you actually want to transport a date value (no time component) over the SOAP service, the easiest solution would be to use the appropriate XML Schema datatype instead of a datetime type.
Use a DateTimeOffset in your .net code and it will work just fine.