Develop Reference

Storing time in Postgres and handling it on Application (Java) side [closed]

Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 3 years ago.
Improve this question
I have heard that postgres supports storing of datetime and time with both timezone and without timezone. Now an application running in JST timezone has to store time on database side. Now for wherever i have read it is suggested that you shall always keep things stored in UTC which can work in case of datetime because upon receiving datetime on application layer i can manipulate it according to my preferred timezone. But if i only want time stored on database side then for that as well shall i store it as UTC time ? If yes then 1 am in JST will result in 4 pm UTC of previous day. so could someone please suggest me what shall be the preferred way of storing time in database ?
As suggest in one of the answer if i read the time in LocalTime then if i store time as 12:00 JST then upon reading on application side it will be 12:00 JST or 12:00 UTC.

If there is even a remote possibility that times will ever be in more than one time zone, then you need to store them in a common well-known time zone, and UTC is the best choice for that.
If you're absolute certain, beyond any shadow of doubt, that the application will only ever be used in a single time zone, and that both application and database servers will run in that time zone, then you can store the times in that local time zone.
Since such certainty is rare, it is recommended to use UTC.
If the original time zone must be retained, you need a separate column to store the time zone, so it can be re-applied when loaded from the database.

tl;dr
Apparently you want to store a time-of-day without a date and without a time zone.
Use the Java class java.time.LocalTime and the standard SQL type TIME WITHOUT TIME ZONE.
LocalTime.of( 15 , 30 )
…and…
myPreparedStatement.setObject( … , LocalTime.of( 15 , 30 ) )
Details
Be aware that an offset-from-UTC is merely a number of hours-minutes-seconds, nothing more. A time zone is much more. A time zone is a history of the past, present, and future changes to the offset used by the people of a particular region.
I have heard that postgres supports storing of datetime and time with both timezone and without timezone.
Actually the SQL standard defines:
TIMESTAMP WITH TIME ZONETrack a moment, a specific point on the timeline. Represents a date, a time-of-day, and an offset-from-UTC or a time zone. Common implementations use UTC.
TIMESTAMP WITHOUT TIME ZONETracks a date and time-of-day but without the context of an offset or zone. So this type cannot represent a moment, is not a point on the timeline. For example, for a value of "noon on the 23rd of January in 2020", we do not know if this means noon in Tokyo, noon in Paris, or noon in Montréal — all very different moments, hours apart.
Now an application running in JST timezone
JST is not a true time zone. Proper time zones have a name in Continent/Region format. Never use the 3-4 letter pseudo-zones such as EST or IST as they are not true time zones, not standardized, and not even unique(!).
ZoneId z = ZoneId.of( "Africa/Tunis" ) ;
If by JST you meant the time in Japan, use Asia/Tokyo.
ZoneId z = ZoneId.of( "Asia/Tokyo" ) ;
to store time on database side to be aware of the time slots.
I have no idea what that means.
Now for wherever i have read it is suggested that you shall always keep things stored in UTC
When tracking actual moments, yes, generally best to do so in UTC, that is, an offset-from-UTC of zero hours-minutes-seconds. Think of UTC as The One True Time, and other offsets & zones as mere variations, as localization issues for presentation of data to users. Do most of your business logic, data storage, data exchange, debugging, and logging in UTC. Keep a second clock on your desk set to UTC, seriously. Programmers and sysadmins should learn to think and work in UTC, leaving behind your parochial time zone while on the job.
which can work in case of datetime because upon receiving datetime on application layer i am manipulate it according to my preferred timezone.
Yes, as discussed above, work your logic in UTC (generally) and present localized to the zone expected by the user. When crucial, confirm with the user their desired time zone. And make a habit of always including the zone/offset info when displaying a date or time, to avoid ambiguity and confusion.
But if i only want time stored on database side then for that as well shall i store it as UTC time. If yes then 1 am in JST will result in 4 pm UTC of previous day. Can someone suggest how shall i store time alone in database side.
Do you mean you want to store just the time-of-day without a date and without a time zone? If so, use:
LocalTime in Java.
TIME WITHOUT TIME ZONE in standard SQL.
The SQL standard bizarrely defines a TIME WITH TIME ZONE type, but this makes no sense. Just think about it. And don’t be surprised; this is not the only anti-feature in the SQL standard. Postgres does offer this type, as following the standard is one of the primary goals of Postgres. Likewise, the java.time framework in Java includes a java.time.OffsetTime class to be compatible, but you will never use it.
Postgres has excellent date-time handling, and does offer the TIME WITHOUT TIME ZONE data types.
LocalTime localTime = LocalTime.of( 15 , 30 ) ;
myPreparedStatement.setObject( … , localTime ) ;
Retrieval.
LocalTime localTime = myResultSet.getObject( … , LocalTime.class ) ;
You might want to apply that time-of-day to a date and time zone to determine a moment by instantiating a ZonedDateTime.
ZoneId z = ZoneId.of( "Asia/Tokyo" ) ;
LocalDate localDate = LocalDate.of( 2019 , Month.JANUARY , 23 ) ;
ZonedDateTime zdt = ZonedDateTime.of( localDate, localTime, z ) ;
See that same moment through the wall-clock time of UTC. Same moment, same point on the timeline, but different wall-clock time.
Instant instant = zdt.toInstant() ;
And adjust to another time zone if desired. Again, same moment, same point on the timeline, but different wall-clock time.
ZonedDateTime zdtMontréal = instant.atZone( ZoneId.of( "America/Montreal" ) ) ;
Perhaps you want to see the time-of-day in Québec for that moment.
LocalTime localTimeMontréal = zdtMontréal.toLocalTime() ;
Here is a table of the various date-time types in Java and in standard SQL.

TimeZone isn't showing

I'm using IntelliJ (Kotlin and Java language), I'm trying to get a report of time by using query from my database and send that to the browser (I'm using Postman to see the result).
When I debug my code and go through the result from the query the timezone is ok like the way I want it, its even show -7 (the difference time between me and the UTC) but when it comes to the browser (Postman) it's showing UTC time and +0000, for example:
"date": "2017-10-12T15:00:33.000+0000"
instead of
"date": "2017-10-12T15:00:33.000+0007".
I tried many options and waste around 6 hours to find the solution but nothing work.

Postgres stores a TIMESTAMP WITH TIME ZONE in UTC, discarding the passed zone after using it to make the adjustment into UTC. Note that this is Postgres-specific behavior – databases vary widely in their date-time handling, and the SQL spec barely touches on the subject.
As commented by Marlowe, if you need to remember the time zone captured from data-entry, you will need to store that in another column. Capture a proper time zone name in the format of continent/region, such as America/Montreal, Africa/Casablanca, or Pacific/Auckland. Never use the 3-4 letter abbreviation such as EST or IST as they are not true time zones, not standardized, and not even unique(!).
➠ Here's the rub: A Postgres session in an interactive tool such as pgAdmin dynamically applies a default time zone after fetching the UTC value. While well-intentioned, this is an anti-feature in my opinion as it obscures the true nature of the stored data.
Fetch the value in UTC using the modern java.time classes.
Instant instant = myResultSet.getObject( … , Instant.class ) ;
Adjust to your desired time zone.
ZoneId z = ZoneId.of( "Asia/Kolkata" ) ;
ZonedDateTime zdt = instant.atZone( z ) ;
Generate a string for the web browser using the DateTimeFormatter class. Note the automatic localization features there.
All this has been covered many times on Stack Overflow. Search to learn more.

Solution: so i found the solution to my problem here:
Overriding BeanPropertyRowMapper to Support JodaTime DateTime
in shortly, timestamp type doesn't work well with timezone so i changed it to DateTime in Joda and wrapped the result of the query by costumed Bean (from the link i posted)

Java 8 - tz database time zones

I have to work with Java 8 dates / times in different time zones. For instance:
LocalDateTime dateTime = LocalDateTime.of(2017, Month.JUNE, 1, 13, 39);
Instant instant = dateTime.atZone(ZoneId.of("Europe/Paris")).toInstant();
and a Time Frame is an instance between to dateTimes
But I don't want to hardcode the Time Zone, that is always a bad practice
I couldn't find any constants in the Java API to represent the diffenent Time Zones like https://en.m.wikipedia.org/wiki/List_of_tz_database_time_zones
Is there any mapping as it was in the short zone IDs ????
https://docs.oracle.com/javase/8/docs/api/java/time/ZoneId.html#of-java.lang.String-java.util.Map-

Time zones are frequently redefined by politicians. New zones appear. Old ones get renamed (ex: Asia/Kolkata). Some are determined to not actually be distinct, and end up pointing to another (ex: America/Montreal). And that is just the names – the offsets within each zone are also often modified by politicians for anomalies such as Daylight Saving Time (DST), or deciding to get off DST altogether or deciding to stay on DST all-year-round or deciding to change the offset by 15 minutes to make some political statement such as distinguishing yourself from your neighboring countries. So there is no simple permanent list.
Java comes with a copy of the tzdata time zone database. If any zones you care about experience a change, you need to update this tzdata in your Java installations. Oracle provides a tool for this chore in their implementation; I do not know about others. Similarly you should also update the tzdata in your host computer’s OS as well as other utilities such as your database like Postgres.
As for references to a ZoneId object in Java, you may define some as constants. The java.time classes are thread-safe. So you may keep a single instance around as a constant.
public class TimeUtils {
static public ZoneId ZONEID_EUROPE_PARIS = ZoneId.of( "Europe/Paris" ) ;
static public ZoneId ZONEID_ASIA_KOLKATA = ZoneId.of( "Asia/Kolkata" ) ;
}
You have a LocalDateTime representing potential moments, not a specific point on the timeline. A LocalDateTime has no time zone or offset information. So a LocalDateTime of noon June 1 this year could mean many different moments, with the first noon happening in Kiribati where the time zone has an offset fourteen hours ahead of UTC. Noon in Bangladesh comes later, and noon in Paris France still hours later. So a LocalDateTime has no real meaning until you apply a time zone for context.
LocalDateTime noon1June2017Anywhere = LocalDateTime.of( 2017 , Month.JUNE , 1 , 12 , 0);
Use those constants where you need a ZoneId.
ZonedDateTime noon1June2017EuropeParis = noon1June2017Anywhere.atZone( TimeUtils.ZONEID_EUROPE_PARIS ) ;
ZonedDateTime noon1June2017AsiaKolkata = noon1June2017Anywhere.atZone( TimeUtils.ZONEID_ASIA_KOLKATA ) ;
Note that noon1June2017EuropeParis and noon1June2017AsiaKolkata are two different moments, different points on the timeline. Noon happens much earlier in India than it does in France.
Let's see those two values in UTC as Instant objects. These two Instant objects are not equal, as the Kolkata one is several hours earlier than the Paris one.
Instant instantNoon1June2017EuropeParis = noon1June2017EuropeParis.toInstant() ; // Extract the same moment but in UTC zone.
Instant instantNoon1June2017AsiaKolkata = noon1June2017AsiaKolkata.toInstant() ; // Extract the same moment but in UTC zone.
Externalize
If the intent of your Question is to externalize the decision of what zone to apply, so that you may change that choice without recompiling your source code again, simply store a string of the zone name such as Europe/Paris as a string in some external resource.
Pass your string to ZoneId.of.
ZoneId z = ZoneId.of( someStringOfZoneName ) ;
Possible storage mechanisms commonly used by folks:
Store the text in a file.
Store the text in a database row to retrieved by your app.
Store the text as an entry in a JNDI facility (LDAP server, a configuration file in your Servlet container, etc.) (see Tutorial)
Query from a Web Service. (See Tutorial)
Ask the user for their preference and store in a variable such as a member of a class, or in a Servlet environment store string as an attribute on the context object or on the session object. You can provide the user with a choice list of all zones by calling ZoneId.getAvailableZoneIds.
You can ask for the JVM’s current default zone: ZoneId.systemDefault. But beware, this can be changed at anytime by any code in any app in that JVM.

new Date() is giving time in UTC in ec2 Instance which is configured as IST

I have an ec2 instance running in Singapore zone. By default time zone for this instance is UTC. So I've set it to IST assuming, application which is running in this instance generates time in IST which we store in the database.
i.e new Date() in my application shoud return time in IST. But it's still generating time in UTC which isn't we needed.
So, how to make new Date() gives time in IST in ec2 instance without adding explicit java code?

Try to set -Duser.timezone="Asia/India" as Environment Variable or run your java app with that switch from terminal using java filename -Duser.timezone="Asia/India"

java.time
ZonedDateTime.now(
ZoneId.of( "Asia/Kolkata" )
)
Details
The toString method of Date confusingly applies the JVM’s current default time zone while generating the string. This misleads you into thinking it has an assigned time zone but does not^. The Date object actually represents a value in UTC. One of many reasons to avoid these troublesome old legacy date-time classes.
This class is now supplanted by the java.time classes.
The Instant class represents a moment in UTC.
Instant instant = Instant.now();
Adjust into your desired time zone. Never use 3-4 letter abbreviations such as IST. Not a real time zone. Use real time zone names.
ZoneId z = ZoneId.of( "Asia/Kolkata" );
ZonedDateTime zdt = instant.atZone( z );
This Question is really a duplicate of many others. Search Stack Overflow for much more discussions and examples.
Do not alter the time zone of your host operating system nor the JVM’s default time zone. You simply should not rely on the default time zone as it can be changed at any moment at runtime by any code in any thread of any app within your JVM. Always specify the optional argument for time zone when calling the java.time classes, problem solved.
^To make things even more confusing, there actually is a time zone within the Date class, but without getters or setters. Used internally, but irrelevant to our discussion here. These old legacy date-time classes are a very confusing mess.

java print date different than the system

I need to set the system date in Centos 6.6 so what i did
cp /usr/share/zoneinfo/Europe/Paris /etc/localtime
And I wrote a small java application to print date and I print the date with the command date and i got this
[root#sandbox ~]# date
Fri May 20 19:13:32 CEST 2016
[root#sandbox ~]# java t
Fri May 20 17:13:35 UTC 2016
I really need to know why i have different time and how to fix it?
And i don't want to make change to the java code i want to fix the system date

We cannot precisely assist you until you post the source code for that little Java app.
Tracking date-time
One general concept you seem to be misunderstanding is that a date-time as tracked by a computer has no time zone. If you are using the old outmoded class java.util.Date, it tracks a number of milliseconds since the epoch reference date of first moment of 1970 in UTC.
Date-time != String
Another concept: A date-time object is not a string. You can generate a String to represent the date-time value in your date-time object, but that string is distinct from the date-time. Remember, internally that date-time is actually a count of milliseconds since 1970 UTC).
Your app is likely calling the toString method on java.util.Date class. That method confusingly applies the JVM’s current default time zone to the stored date-time creating the false illusion that the java.util.Date has that zone assigned.
Default time zone
The default time zone is usually picked up from the host OS when the JVM launches, but not always. Configuration flags for the JVM may indicate another time zone as default. And any code in any thread of any app within the JVM can change the JVM’s default time zone at any moment, during runtime! Because of being undependable, I suggest you avoid using the default, and instead always specify the desired/expected time zone.
Generally best practice is to keep servers on UTC. But I do not want my app to be vulnerable to such externalities as some sysadmin changing the server’s time zone, I always specify the desired/expected time zone in my Java code (shown further down).
No problem
So you have no problem to fix. Paris time (CEST) of 19:13:3x is two hours ahead of UTC, which your Java app is correctly showing as 17:13:3x for UTC time zone. These values make sense. These two date-time strings are two different representations of the very same moment on the timeline.
If you want a Paris time in your Java app, ask for a Paris time (shown further down below). If you want UTC, ask for UTC in your Java app (also shown further down).
As to why your Java app is showing the time in UTC remains a mystery until you show us your source code.
In the mean time, I can show the basics of capturing the current time and adjusting into a desired time zone.
java.time
You are use old date-time classes that have proven to be troublesome, confusing, and flawed. Avoid them. These old classes have been supplanted by the java.time framework built into Java 8 and later. Much of the java.time functionality has been back-ported to Java 6 & 7 in ThreeTen-Backport and further adapted to Android in ThreeTenABP.
An Instant is the current moment on the timeline in UTC, with resolution of nanoseconds (finer than the milliseconds in java.util.Date).
Instant instant = Instant.now();
Generally best to much of your business logic, database storage, other storage, and data exchange in UTC. So make frequent use of Instant.
Wall-clock time
Apply a time zone to get the wall-clock time for some locality. Apply a ZoneId to get a ZonedDateTime.
ZoneId zoneId = ZoneId.of( "Europe/Paris" );
ZonedDateTime zdt = ZonedDateTime.ofInstant( instant , zoneId );
Generating ISO 8601 strings
The toString methods in java.time by default generate strings in the standard ISO 8601 formats. The ZonedDateTime class’ toString method extends the standard by appending the name of the time zone in square brackets.
String output = instant.toString();
2016-05-21T00:52:53.375Z
String output = zdt.toString();
2016-05-21T02:52:53.375+02:00[Europe/Paris]
You can adjust into yet another time zone. Notice the date being previous to that of Paris, 20 versus 21 of May (still “yesterday” in Montréal).
ZonedDateTime zdt_Montréal = zdt.withZoneSameInstant( ZoneId.of( "America/Montreal" ) ) ;
2016-05-20T20:52:53.375-04:00[America/Montreal]
So we have generated three different textual representations of the very same moment on the timeline (UTC, Paris, & Montréal).
Time zones
Avoid using 3-4 letter zone abbreviations like CEST. These are neither standardized, nor unique(!). Furthermore, they are not true time zones. Always use proper time zone names, in the format of continent/region.

if you don't like or you can't change java code then you have to change server/system/centos timeZone, First you have to see list of possible timezones in
ls /usr/share/zoneinfo
and result
see we have date Sat May 21 02:54:11 IRDT 2016 we are now going to change you need to change (or set) the symbolic link /etc/localtime so make a backup of the existing `localtime file
sudo mv /etc/localtime /etc/localtime.bak
Next, create the link:
sudo ln -s /usr/share/zoneinfo/America/Chicago /etc/localtime
Make sure to replace America/Chicago with the directory (if your zone has one) and filename of the timezone you wish to use for example
sudo ln -s /usr/share/zoneinfo/UTC /etc/localtime
Now you just need to test your change. Run date from the command line, i done it and result are
and for see huge list of timezone click here

Make sure you also check your /etc/timezone file and adjust accordingly

Ok first you should think of using #Basil-Bourque answer to change your code. it's a good practice
and for changing you Centos timezone try to export TZ to Europe/Paris like the following
export TZ="Europe/Paris"