I'm trying to save data about date and time to List. Let's say, I have List<Date>. I have 2 types of formatting of strings: dd/mm/yy and hh:mm. Well, I'm able to easily format and create an instance of java.util.Date using SimpleDateFormat. However, when I try to print the object, the one that I saved time data into prints something like this:
Thu Jan 01 06:30:00 AZT 1970
How do I differentiate between these two and get the following output instead:
06:30
Note: Years may start earlier than 1970.
Thanks for the help and appreciate the effort.
How to know if a Date object represents only Time in Java?
There is no way to do this reliably. Every value of Date that you are using to represent a time also represents a valid date. And you can't distinguish the two cases ... except by using an unreliable heuristic.
The real problem is that you should not use Date to represent times.
A Date represents a single point in the time continuum.
A time is either a duration or multiple time points depending on how you use it. (It depends on your use-case.)
In fact, you probably not be using java.util.Date at all. Date is legacy Java class that has many API flaws. It was superseded in Java 8 by the classes and interfaces in the java.time package. These provide distinct classes for the various different concepts.
I recommend that you read the Date-Time trail in the Oracle Java Tutorial to get a basic understanding. This will help you decide the correct classes to choose for your use-case.
Time is complicated in the real world, and it is complicated in Java too.
This question already has an answer here:
ZonedDateTime change behavior jdk 8/11
(1 answer)
Closed 2 years ago.
I am trying to parse dates from strings to ZonedDateTimes and I've come across a bizzare problem.
2020-11-01T01:00-05:00[America/New_York]
This is an hour right after time EDT ends this year. When I pass it to ZonedDateTime.parse I get
ZonedDateTime.parse("2020-11-01T01:00-05:00[America/New_York]")
// 2020-11-01T01:00-04:00[America/New_York]
but if I do
ZonedDateTime.parse("2020-11-01T01:00-04:00[America/New_York]").plusHours(1)
I get
2020-11-01T01:00-05:00[America/New_York]
So it's not like Java cannot represent this ambiguous value or something..
Can anyone explain to me that behavior and possible solution?
Note: I am using Java 8
As Amir Schnell said in the comments, this seems to be a bug in the JDK, as they cannot reproduce this in Java 11.
For now, I have found this work around:
Parse the string into a local date time, zone ID, and zone offset, and create a ZonedDateTime using those three things:
TemporalAccessor ta = DateTimeFormatter.ISO_ZONED_DATE_TIME.parse("2020-11-01T01:00-05:00[America/New_York]");
System.out.println(
ZonedDateTime.ofLocal(
LocalDateTime.from(ta),
ZoneId.from(ta),
ZoneOffset.from(ta)
)
);
This question already has answers here:
SimpleDateFormat with TimeZone
(6 answers)
Closed 4 years ago.
Currently we are using
DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ss.SSSX")
To format the time range to an external vendor for a range of data, for India, that formatter will give time like this:
2018-04-26T00:00:00.000+0530
However, my vendor say they cannot accept this format and it have to look like
2018-04-26T00:00:00.000+05:30
However, look like in DateTimeFormatter, whatever I choose Z/z/X/x, I don't get that format of offset. Just wonder is that a way to customize the offset to be HH:mm?
Or, I need to get the offset in second and work that our myself?
It is three x. Just tried with JavaRepl:
java.time.format.DateTimeFormatter
.ofPattern("yyyy-MM-dd'T'HH:mm:ss.SSSxxx")
.withZone(java.time.ZoneId.systemDefault())
.format(java.time.Instant.now())
Results in
java.lang.String res10 = "2018-04-27T11:06:50.648+00:00"
After some trial and error, I saw that this is also documented in the API documentation of DateTimeFormatter but it is not easy to find (buried in a lot of other text):
Three letters outputs the hour and minute, with a colon, such as '+01:30'
DateTimeFormatter API Documentation
This question already has answers here:
Parsing time strings like "1h 30min"
(8 answers)
Closed 6 years ago.
Is there any libraries that is able to take a string such as 5d 1h 2m 15s and add it to a java date / java Calendar?
ie a system property will be set as 5d 1h 2m 15s
We will read in the system property and add this amount of time to the current date.
Otherwise I will have to implement this as a long in milliseconds.
you'll need a bit of parsing to extract the component element but Joda-Time's duration should help you out
http://joda-time.sourceforge.net/apidocs/org/joda/time/Duration.html
If you are using Java8 joda-time's concept were integrated so no need to external dependencies
https://docs.oracle.com/javase/8/docs/api/java/time/Duration.html
once you have a duration adding it to the current date time should be trivial
Java8 and jodaTime
Instant ajustedTime = Instant.now().plus(yourDurationInstance);
you can convert to and from Java's date pretty easily, others have already answered here
After doing my research I wasn't able to find a method or data type that should be used for variable in order to store time in format of HH:MM, I did find methods to get this from a string like "14:15:10", but I think this is not the best way, as I'll need to add or subtract from time. I tried doing this as a double, but ran into following issue, when you have a time like 05.45 stored and add 0.15 (or 15 minutes) to it, the result is 05.60 where as with HH:MM format you'd expect it to be 06.00.
I'm looked through java documentation and still am, but can't seem to find any way to achieve this, closest I got to is date format like dd/mm/yyyy hh:mm:ss
Use Joda Time. It provides much better operations to do date/time manipulation than standard java dates. If you want to use internal JDK classes, use java.util.Date.
Since Java 8, you can use the new API for dates and times, including Instant, ZonedDateTime and LocalDateTime. This removes the use for the third party library Joda time. It also makes calculations more easy and correct. The advice below is a bit dated but still has some good points.
—————
What you definitely should NOT do is store them in your own custom format. Store the Long value that represents the Unix Epoch.
A DateTime is nothing more than a number to a computer. This number represents the amount of seconds (or milliseconds) since 1970-01-01 00:00:00 UTC. It's beyond the scope of this answer to explain why this date was universally chosen but you can find this by searching for Unix Epoch or reading http://en.wikipedia.org/wiki/Unix_time.
This also means there is NO timezone information stored in a DateTime itself. It is important to keep this in mind when reasoning about dates and times. For things such as comparing DateTime objects, nothing concerning localization or timezones is done. Only when formatting time, which means as much as making it readable to humans, or for operations such as getting the beginning of the day, timezones come into play.
This is also why you shouldn't store the time like 20:11:15 in a string-like format because this information is meaningless without timezone information. I will give you 1 example here: Consider the moment when the clock is moved back 1 hour, such as when moving away from daylight savings time. It just happened in a lot of countries. What does your string 02:30 represent? The first or the second one?
Calculations such as subtraction are as easy as doing the same with numbers. For example: Date newDate = new Date(date1.getTime() - date2.getTime());. Or want to add an hour to a date? Date newDate = new Date(oldDate.getTime() + 1000 * 60 * 60);
If you need more complex stuff then using Joda time would be a good idea, as was already suggested. But it's perfectly possible to just do even that with the native libraries too.
If there's one resource that taught me a lot about date/time, it would be http://www.odi.ch/prog/design/datetime.php
Java has java.sql.Time format to work with time-of-day values. Just import it and create variables.
import java.sql.Time;
//now we can make time variables
Time myTime;
Just saw it on https://db.apache.org/derby/docs/10.4/ref/rrefsqlj21908.html
The answer that is right for your case depends on what you want to do.
Are you using a RDBMS as your persistence engine?
If so, are you already working with legacy data formats or are you building a database from the ground up?
Are you simply storing this data, or will you be doing extensive date arithmetic and/or precedence calculations?
Are you in one time zone or do you need to work with time instants across many time zones?
All of these things are important and factor into your decision of how to represent your times and dates.
If your needs require a lot of date arithmetic (eg. determining days between dates) or sorting based on timestamps, then consider using a floating point date format. The advantage of using a numeric format for timestamps is that doing date arithmetic and comparison/sorting operations becomes trivial; you merely do simple arithmetic. Another advantage is that floats and longs are primitive data types. They do not need to be serialized, they are already extremely lightweight, and everything you need to use them requires no external dependencies.
The main disadvantage to using numeric formats for timestamps is that they are not human friendly. You'll need to convert them to and from a String format to allow users to interact. Oftentimes, this is worth the effort. See: How do I use Julian Day Numbers with the Java Calendar API?
I recommend that you consider storing timestamps as Julian Day Numbers (JDNs) or Modified Julian Day Numbers (MJDs). Both will represent dates and times to millisecond precision using an 8 byte float. Algorithms for converting to and from display formats for both of these are highly standardized. They confer all the advantages of using numeric dates. Moreover, they are defined only for GMT/UTC which means that your timestamps are already universalizable across time zones right out of the box (as long as you localize properly).
If you dont want the full date object, your best bet is to store it in a string, but I personally would still recommend date as it also contains a lot of convenient methods that will come in handy. You can just get the time as a whole from a date object and ignore the rest.
In terms of "storing" a date, you should use a long. This is how the system sees it and how all calculations are performed. Yes, as some point out you will eventually need to create a String so a human can read it, but where people run into trouble is when they start thinking of a date in terms of format. Format is for readability, not for calculations. java.util.Date and java.util.Calendar are fraught with issues (Effective Java, Bloch, et. al. has plenty to say about it) but are still the norm if you need handy date operations.