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.
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 some Java code interacting with Cassandra. I was wondering if there is any way to adjust the timezone for displaying (not for storing) columns of TIMESTAMP types.
As far as I understand, Cassandra's TIMESTAMP type is essentially a number of milliseconds since the epoch[2], hence there is no notion of timezone for the type and the viewer shows the time as in UTC.
Here's what I have tried:
According to JetBrains documentation, there's a JVM option user.timezone to make this kind of adjustment. So I've set the JVM option of the Cassandra driver as -Duser.timezone=Asia/Seoul, but it appears to have no effect whatsoever. Also tried -Duser.timezone=UTC+09:00 and it didn't work either.
Is there any way to make the viewer to show the times in a different timezone?
Java doesn’t recognize UTC+09:00 as a time zone ID.
Use for example -Duser.timezone=Asia/Pyongyang or an even better suited ID in the region/city format, or -Duser.timezone=Etc/GMT-9 if you insist on giving an offset rather than a time zone. In the latter case note the inverted sign, -9 for +09:00.
Recognized time zone IDs are in List of tz database time zones.
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 have a date stored in a database as a UTC date ('2015-04-24 00:00:00'). When I get this date (using Hibernate) on a server running in the Eastern US Timezone, is shown as the correct date, '2015-04-24 00:00:00'. However, when I get this data on a server running on AWS in the us-west-1 region, which I assume is Pacific Time, the date shows as '2015-04-23 20:00:00'. Does anyone know why this would happen? I assume it has something to do with the date converting to local time, rather than UTC, but how can I prevent this from happening? Thanks!
Short answer: Just convert your Date to utc
Somewhat longer answer: As long as we don't consider relativistic effects a date (or more appropriately named a point in time) doesn't have a time zone. But if you display it as a String there are many variants of displaying it. One kind of variation is the choice of a timezone.
If you don't take special care to use a specific time zone, many programs will choose the timezone that the machine is 'living' in, which is configured on the os level and set to the time zone that is apropriate for the location the computer is most of the 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?