I'm creating a sqlite database from my c# project which will be used in my android application later on.
I have a CreateDate column in my sqlite database which I will need to get records ordered by this column later in my android application. Now my question is that is it better to save the date time as TEXT with YYYY-MM-DD HH:MM:SS format or I just convert all my dates into miliseconds and order them easily later since it's just a number?
Which one is easier to be ordered later in mobile application? or maybe my approaches are wrong so please feel free to shoot me with some best practices for this situation.
Thanks in advance.
Well unix timestamp looks simple and easier but i wont recommend you this.
Check out this gif.
What happens on January 19, 2038?
On this date the Unix Time Stamp will cease to work due to a 32-bit overflow. Before this moment millions of applications will need to either adopt a new convention for time stamps or be migrated to 64-bit systems which will buy the time stamp a "bit" more time.
Therefore i would suggest you to stick with YYYY-MM-DD HH:MM:SS format as it is both C# and Android compatible(or parseable i should say) and neither would string overflow in near future ;)
Good Luck.
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
I'm writing a toy logistics service. As a result, products will travel through lots of different timezones, and I'll need to query both the strict ordering of events, as well as what hour of day it is for products (for example, what happened when the sun was at its hottest, at 1200).
At the moment, I'm saving jodatime DateTimes and trying to deal with them exclusively, but I know time is mighty tricky, and I'm wondering if I need to do anything else to make sure it all works.
Given that you're recording events as they occur (rather than planning for future events), you probably don't need to worry about changes to time zone rules which occur in the future.
As such, it would be reasonable to store a timestamp (e.g. as UTC) and also the time zone ID for the location of the event. To make querying easier, you could also store the local time at the time of the event. Just be aware that as a toy is travelling through time zones, there could be multiple events at different instants in time, all of which occur at "midday" on the same day (but in different zones). You really need to think carefully about what queries you really want to perform on the local date/time values.
I am not familiar with jodatime but when I need to store the time I always enjoy using Epoch time because it is very easy to manipulate to get different formats. If you're interested in it here is a converter website that I find very helpful: http://www.epochconverter.com/
I have a list of Java time zone ids and want to convert these into Python time zone ids. One way to do it is to build a dictionary manually which maps Java time zone ids to Python time zone ids. Is there any other way by which I can do this? I am working on python 2.7.6.
There's nothing to convert. Both Java and Python (via pytz or dateutil) work with the same set of time zones from the tz database.
If you see differences, then it may be because one of your environments doesn't have a current version. New time zones are released occasionally, but old ones are never removed. They're just converted to links to maintain backwards compatibility.
If you have a specific example where you see a zone in one but not the other (which shouldn't happen), then please update your question with the details.
See also: the timezone tag wiki.
http://tutorials.jenkov.com/java-date-time/java-util-timezone.html
Python - Pytz - List of Timezones?
Pass the time and string of timezone. Hopefully Python contains the one you're looking for
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.
I need to add timezone information to a db table with user maintained locations. The data will be accessed mostly from Java code but there is also some PL/SQL and Win32 (Delphi) code which needs to understand the timezone information.
It seems straight forward to use the id from java.util.TimeZone. Java can easily convert that (obviously), Hibernate has built-in support for it and apparently also Oracle understands those timezone ids:
select TZ_OFFSET('Pacific/Marquesas') from dual.
The problem is: the timezone ids do not seem to be compatible with the Windows Timezone DB. For example, the java.util.timezone id "Pacific/Marquesas" (-09:30) is not in the timezone picklist in Windows. The registry does not contain it at all; see
\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones
Here I can only pick either -09:00 or -10:00. So, if I were to store the timezone like this, how can I get to the actual offset/DST infos in Windows (without Java)? Hopefully this does not require a mapping table which I have to keep up to date whenever it changes. Is there a globally accepted standard which works better than the java timezone id?
Update
The timezone info is used in combination with DATE columns on the database. Those columns contain local date/time values. If a location can be associated with those values, the location's timezone enables me to convert the date/time value to UTC or any other timezone whenever needed.
I realize that instead of DATE a TIMESTAMP_TZ data type or something similar would be more appropriate. However, this would require a data migration (for which the TZ is required again) and is not supported by the legacy applications which also work on the data (unless a lot of code is changed). The problem is almost the same if I had to convert the values to UTC.
Bottom line is I need to keep the DATE values in local time but I need to know for some of them which TZ that means.
I can give a little background, if not a real answer.
Many systems use the Olson implementation of timezone data. So those names work in many systems (most Unix, Java, Oracle I think). Microsoft does their own thing.
I see at the bottom of that Wikipedia link there's a reference to some mapping to the Windows world.
Good luck!
I realize this is not the best way to do it, but it might be sufficient in your case. Without knowing all the requirements I can't tell.
What do you need to use the time zone information for? Just to present the time with the correct offset and maybe also the name of the time zone?
You could continue to use Java to determine what the offset of the user is by looking up the user's selected time zone using Java. Each time the user logs in record in your database what the offset currently is. Then other apps can look at this information to determine how to format the time.
This assumes that users who regularly login are the ones that this needs to be done for. If that's not the case you could run a daily job to lookup the time zone for each user in Java and record the offset currently in effect.
Hackish, agreed, but the only other way I see is to maintain a mapping. And what happens when someone selects a time zone that you don't have a mapping for?