Compare String time to Local Server Time - date

Have a string object with a specific format of date.
Need to check if that dateStr is after the current time on local machine.
Having trouble with conversions and LocalDateTime
String dateStr = "Oct 27 2017 02:29:00 GMT+0000";
public static final String DATE_FORMAT = "MMM dd yyyy HH:mm:ss zzzZ";
I know something is fishy in the below code with the usage of LocalDateTime
public static boolean isFutureDate(String dateStr){
DateTimeFormatter formatter = DateTimeFormatter.ofPattern(DATE_FORMAT);
LocalDateTime dateTime = LocalDateTime.parse(dateStr, formatter);
return(dateTime.isAfter(LocalDateTime.now()));
}
Trouble is with timezones and date conversions.
Please help find the right way of checking if a dateStr is after the current local date this in Java 8?

Local… types have no time zone
You are using the wrong type for your data.
The Local… types including LocalDateTime purposely have no concept of time zone or offset-from UTC. As such they not represent a moment on the time line, only rough idea of a range of possible moments. Use LocalDateTime only when the time zone is unknown or irrelevant; never use it for an actual moment in history.
Use OffsetDateDate for values with an offset-from-UTC, a number of hours and minutes.
Use ZonedDateTime for values with an assigned time zone. A time zone such as Asia/Kolkata or America/Montreal is a particular region’s history of past, present, and future changes to its offset-from-UTC. Anomalies such as Daylight Saving Time (DST) mean a change to the offset.
If you know all your inputs are in GMT/UTC, use OffsetDateTime. If the inputs may use time zones, parse as ZonedDateTime objects.
This input data format is terrible. If you have any control, use standard ISO 8601 formats instead when exchanging date-time values as text.
All this has been covered many times already on Stack Exchange. Please search more thoroughly before posting. And search Stack Overflow to learn more. I kept my Answer here brief, as this is a duplicate.

When parsing to a LocalDateTime, you're ignoring the offset (+0000), and I'm not sure if that's what you really want.
In this case, the +0000 offset means the date/time is October 27th 2017 at 02:29 AM in UTC. When you parse to a LocalDateTime, you're ignoring the offset (so it represents only "October 27th 2017 at 02:29 AM", not attached to any timezone) and comparing to your local date/time (or the current date/time in the JVM's default timezone).
If you want to make a comparison that also considers the offset, you can parse it to OffsetDateTime and convert to Instant to compare it with the actual UTC instant, regardless of the timezone.
Also, the month name is in English (I'm assuming it's English, but you can change this accordingly), so you must a java.util.Locale in the formatter (if you don't set a locale, it'll use the JVM default, and it's not guaranteed to always be English):
// parse to OffsetDateTime (use the same formatter)
String dateStr = "Oct 27 2017 02:29:00 GMT+0000";
DateTimeFormatter fmt = DateTimeFormatter.ofPattern("MMM dd yyyy HH:mm:ss zzzZ", Locale.US);
OffsetDateTime odt = OffsetDateTime.parse(dateStr, fmt);
// compare Instant's
System.out.println(odt.toInstant().isAfter(Instant.now()));
Although it works for you now, keep in mind that the default locale can be changed without notice, even at runtime. If your input has locale-sensitive date (such as month names), it's better to specify it as above.

Related

ZonedDateTime value incorrect after loading via Spring Boot JPA, PostgreSQL

I have a ZonedDateTime with a specific instant in time, with the Zone set to America/Los_Angeles.
If I display this using the pattern "d-MMM-uuuu HH:mm VV" it shows as I expect (e.g. ... 8:00 am America/Los_Angeles).
However, if I change the pattern very minimally by removing the "VV", then it does not show the time in west coast time, it shows it in my local time (east coast), or 11:00 am - so it essentially ignores the zone set on the ZonedDateTime and instead uses something else (I assume the system local zone).
I would prefer to not display the time zone id in some cases, to save space (in a table for instance), but still want it to be displayed in the local time.
Is there a way to do that?
Update:
I note that using the pattern "d-MMM-uuuu HH:mm O", surprisingly, gives what I consider a wrong answer:
2-Jun-2020 11:09 GMT-7
here is the correct time, which shows using VV:
2-Jun-2020 08:09 America/Los_Angeles
The 11am value with "GMT-7" looks like it is clearly a bug - granted I am still using Java 8.
Update:
I think the problem may be in the data layer, though I am still trying to figure that out... (I am using Spring Boot JPA and PostgreSQL).
If I just purely use Java, as such:
ZoneId pdt = ZoneId.of("America/Los_Angeles");
ZonedDateTime now = ZonedDateTime.now().withZoneSameInstant(pdt);
logger.debug("now with VV: "+now.format(DateTimeFormatter.ofPattern("d-MMM-uuuu HH:mm VV")));
logger.debug("now with O: "+now.format(DateTimeFormatter.ofPattern("d-MMM-uuuu HH:mm O")));
logger.debug("now with nothing: "+now.format(DateTimeFormatter.ofPattern("d-MMM-uuuu HH:mm")));
logger.debug("now with VV+withZ: "+now.format(DateTimeFormatter.ofPattern("d-MMM-uuuu HH:mm VV").withZone(pdt)));
logger.debug("now with O+withZ: "+now.format(DateTimeFormatter.ofPattern("d-MMM-uuuu HH:mm O").withZone(pdt)));
logger.debug("now with nothing+withZ: "+now.format(DateTimeFormatter.ofPattern("d-MMM-uuuu HH:mm").withZone(pdt)));
logger.debug("using static formatter: "+now.format(TIMESTAMP_FORMATTER_SHORT));
logger.debug("using static formatter w/zone: "+now.format(TIMESTAMP_FORMATTER_SHORT.withZone(pdt)));
then in every case it shows the expected correct time in LA.
So, in debugging to see the differences, I see this anomaly:
In plain java if I look at the value of now (in code above), it looks correct - the LocalDateTime shows the current time in LA, and the offset is 7 hrs.
If I look at the ZonedDateTime value that is set after the JPA load, however, it looks unusual:
the value stored in the DB has the hour at 15 (as expected, UTC time)
the value in the LocalDateTime within the ZonedDateTime is off - it is showing the hour as 11, which is the local system time, not the time in LA
however the ZonedDateTime offset is still -7
What is really odd about this is that somehow DateTimeFormatter corrects the problem, but only when I use VV in the format.
I have determined the problem (not with JPA or PostgreSQL unsurprisingly).
Rather this is a bug that had been introduced a long time ago, but never exposed until I switched to trying to show a shorter display of the timestamp.
The code actually causing the problem was post processing a native query, incorrectly converting a java.sql.Timestamp into a ZonedDateTime. Here is the problem code:
java.sql.Timestamp timestamp = (Timestamp) objects[0];
String tzId = (String) objects[1];
ZonedDateTime dt = ZonedDateTime.of(timestamp.toLocalDateTime(), ZoneId.of(tzId));
I was incorrectly assuming that the ZonedDateTime.of would use the provided ZoneId to revise the time, but I believe that is not how it works. Instead, the toLocalDateTime() was creating a LocalDateTime based on the system default, which therefore did not agree with the ZoneId value passed in, which was the value stored in the DB and not the same as the system default.
Here is how I corrected the code:
java.sql.Timestamp timestamp = (Timestamp) objects[0];
String tzId = (String) objects[1];
ZonedDateTime dt = ZonedDateTime.of(timestamp.toLocalDateTime(), ZoneId.systemDefault())
.withZoneSameInstant(ZoneId.of(tzId));

Why is my UTC instant not converting to BST?

I have the following code:
SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss'Z'", Locale.UK);
Instant inst = DateTimeUtils.toInstant(sdf.parse("2019-08-13T18:00:00Z"));
DateTimeFormatter formatter = DateTimeFormatter.ofPattern("HH:mm").withLocale(Locale.UK).withZone(ZoneId.of("Europe/London"));
System.out.println(formatter.format(inst));
//prints 18:00
This is surprising to me as I thought inst would be a GMT/UTC time and the formatter would format it to London time (which is BST (UTC+1:00) for this date), producing 19:00.
What am I missing here?
I'm guessing this is a generic issue with my code, but if it makes a difference this is using the org.threeten.bp.* classes from the ThreeTen-Backport project, further adapted for early Android in the ThreeTenABP project.
tl;dr
Instant // Represent a moment in UTC.
.parse( // Generate a `Instant` object from the content of text input.
"2019-08-13T18:00:00Z" // String in standard ISO 8601 format.
) // Returns a `Instant` object.
.atZone( // Adjust from UTC to the wall-clock time used by the people of a particular region (a time zone).
ZoneId.of( "Europe/London" ) // Specify a time zone using name in proper `Continent/Region` format. Never use 2-4 letter pseudo-zones such as `BST`.
) // Returns a `ZonedDateTime` object.
.toLocalTime() // Extract the time-of-day, without a date and without a time zone or offset. Returns a `LocalTime` object.
.format( // Generate text representing the content of this `LocalTime` object.
DateTimeFormatter
.ofLocalizedTime ( FormatStyle.SHORT ) // Automatically localize while generating a `String`.
.withLocale ( Locale.UK ) // Locale determines the human language and cultural norms to use in localizing.
) // Returns a `String` object.
19:00
Avoid legacy date-time classes
Your are mixing the terrible legacy classes (SimpleDateFormat, Date) with the modern java.time classes. Don’t do that. Use only java.time.
Instant = moment in UTC
Skip your first two lines of code. Your input string "2019-08-13T18:00:00Z" is in standard ISO 8601 format. These standard formats are used by default by the java.time classes when parsing/generating strings. So no need to specify a formatting pattern.
String input = "2019-08-13T18:00:00Z" ;
Instant instant = Instant.parse( input ) ;
instant.toString(): 2019-08-13T18:00:00Z
Instant is not flexible
I suspect your problem was in your attempt to format the value within a Instant. The Instant class is a basic building-block class within java.time. It merely represents a moment in UTC. It is not intended for things such as flexible generation of strings.
The more flexible classes are OffsetDateTime & ZonedDateTime classes.
ZonedDateTime
Apply a ZoneId to your Instant to adjust into a time zone, rendering a ZonedDateTime object.
ZoneId z = ZoneId.of( "Europe/London" ) ;
ZonedDateTime zdt = instant.atZone( z ) ;
zdt.toString(): 2019-08-13T19:00+01:00[Europe/London]
You seem to want to focus on the time-of-day alone. Extract a LocalTime object.
LocalTime lt = zdt.toLocalTime ();
lt.toString(): 19:00
For the London region in Daylight Saving Time (DST) on that date, the offset-from-UTC is one hour ahead. So we see the time-of-day is 7 PM versus the 6 PM of UTC.
Proper time zone
By the way BST is not a time zone. I suggest you avoid using these pseudo-zones.
Specify a proper time zone name in the format of Continent/Region, such as America/Montreal, Africa/Casablanca, or Pacific/Auckland. Never use the 2-4 letter abbreviation such as BST or EST or IST as they are not true time zones, not standardized, and not even unique(!).
ZoneId z = ZoneId.of( "Africa/Tunis" ) ;
Use smart objects, not dumb strings
Your example code suggests you are too focused on strings. Use smart objects, not dumb strings.
Get your objects straight, using appropriate types. Generating strings should be the last step, a side-effort, akin to localization. Your business logic should be done by using proper objects, not by manipulating strings.
Localization
And speaking of localization:
Locale locale = Locale.UK;
DateTimeFormatter f = DateTimeFormatter.ofLocalizedTime ( FormatStyle.MEDIUM ).withLocale ( locale );
String output = lt.format ( f );
19:00:00
Switch the locale to Locale.US for a different kind of result:
7:00:00 PM
All the code above was run in Java 13 early-access with the ThreeTen-Backport library per your needs stated in the Question.
import org.threeten.bp.* ;
import org.threeten.bp.format.* ;
Note to the reader: The ThreeTen-Backport library is further adapted for early Android in the ThreeTenABP library. See How to use ThreeTenABP in Android. If using Android 26 and later, the java.time classes are bundled, so you do not need the back-port at all.

Is this a valid time?

I get the following datetime String from a backend system: 2014-06-10+02:00.
Is this a valid datetime? There is no information about the time (I get only the date) but there is a time offset.
If it is valid according to which standard is this valid and what is the UTC time?
Thanks a lot
This is a valid date, not a date-time.
An offset-from-UTC is relevant to a date. For any given moment the date varies around the globe by time zone. For example, a few minutes after midnight in Paris France is a new day while still “yesterday” in Montréal Québec.
By the way, an offset-from-UTC is not a time zone. A time zone is a history of changes (past, present, and future) to the offset used by a particular region. A time zone has a name in format of continent/region such as America/Montreal.
With a date and an offset, you can determine the range of all moments occurring in that day, all the points on the timeline.
Example code in Java.
ZoneOffset offset = ZoneOffset.parse( "+02:00" );
LocalDate ld = LocalDate.parse( "2014-06-10" ) ;
OffsetDateTime odt = OffsetDateTime.of( ld , LocalTime.MIN , offset );
https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html
The output is valid Date but not a valid Time as per ISO Date Specification. Please see ISO_OFFSET_DATE.
UTC (Coordinated Universal Time) is a time standard is defined by International Telecommunications Union.
If it is valid according to which standard is this valid and what is
the UTC time?
You have asked three questions in this line and the answer to these questions are as follows:
Is it valid?
Yes, it is a valid date string.
You have already mentioned in your question that it does not have a time part; rather, it has a (timezone) offset of +02:00 hours. So, it is just a valid date string, not a date-time string.
Which standard is this?
This is ISO 8601.
What is the UTC time?
A date starts with the start-of-the-day time which, in most cases, is 00:00 hours. However, for the timezones that observe DST, it may not be the case. Such timezones have generally one hour difference in the timezone offset between with and without DST.
Your string has a fixed (timezone) offset (+02:00); rather than a timezone itself (e.g. Africa/Cairo) and therefore, in this case, the start of the day is always 00:00 hours.
So, it can be written as 2014-06-10'T'00:00:00+02:00. As soon as you represent it in this way, I am sure you must have already guessed that it is equivalent to 2014-06-09'T'22:00:00Z where Z is the timezone designator for zero-timezone offset. It stands for Zulu and specifies the Etc/UTC timezone (which has the timezone offset of +00:00 hours).
Enough talking, let's write some code.
import java.time.OffsetDateTime;
import java.time.ZoneOffset;
import java.time.format.DateTimeFormatter;
import java.time.format.DateTimeFormatterBuilder;
import java.time.temporal.ChronoField;
import java.util.Locale;
public class Main {
public static void main(String[] args) {
String str = "2014-06-10+02:00";
DateTimeFormatter dtf = new DateTimeFormatterBuilder()
.appendPattern("u-M-d['T'[H[:m[:s]]]]XXX")
.parseDefaulting(ChronoField.HOUR_OF_DAY, 0)
.parseDefaulting(ChronoField.MINUTE_OF_HOUR, 0)
.parseDefaulting(ChronoField.SECOND_OF_MINUTE, 0)
.toFormatter(Locale.ENGLISH);
OffsetDateTime odt = OffsetDateTime.parse(str, dtf);
System.out.println(odt);
OffsetDateTime odtUtc = odt.withOffsetSameInstant(ZoneOffset.UTC);
// The default format omits second and fraction-of-second if they are zero
System.out.println(odtUtc);
// Custom format
DateTimeFormatter formatter = DateTimeFormatter.ofPattern("uuuu-MM-dd'T'HH:mm:ssXXX", Locale.ENGLISH);
System.out.println(formatter.format(odtUtc));
}
}
Output:
2014-06-10T00:00+02:00
2014-06-09T22:00Z
2014-06-09T22:00:00Z
Learn more about the the modern date-time API* from Trail: Date Time.
* For any reason, if you have to stick to Java 6 or Java 7, you can use ThreeTen-Backport which backports most of the java.time functionality to Java 6 & 7. If you are working for an Android project and your Android API level is still not compliant with Java-8, check Java 8+ APIs available through desugaring and How to use ThreeTenABP in Android Project.
yes it is correct date format.There are lot of place jerusalam..etc with the +2 hour you can find it in your system.

joda time ISO DateTime formatting

I'm using joda time to format my ISO Date input string, but I'm getting an exception that my ISO Date is malformed:
Invalid format: "2014-06-20T11:41:08+02:00" is malformed at "+02:00"
This is my code:
val formatter: DateTimeFormatter = ISODateTimeFormat.dateTime.withZone(DateTimeZone.getDefault)
val date: DateTime = formatter.parseDateTime("2014-06-20T11:41:08+02:00")
What's wrong here?
The error comment is slightly misleading here, as Joda formatter you derive from ISODateTimeFormat expects the millisecond part of the date/time string to be present, therefore the following will work fine:
val formatter: DateTimeFormatter = ISODateTimeFormat.dateTime().withZone(DateTimeZone.getDefault())
val date: DateTime = formatter.parseDateTime("2014-06-20T11:41:08.0+02:00")
The answer by Radyk is correct.
ISO 8601 Formats Built-In
However, you needn't specify a formatter at all. The DateTime class has a built-in parser for your ISO 8601 compliant format, used automatically by the constructor.
DateTime dateTime = new DateTime( "2014-06-20T11:41:08+02:00", timeZone );
While the second argument is optional, I suggest you assign a DateTimeZone object to be assigned to the DateTime if you know such a time zone. The input string has an offset-from-UTC, but a time zone is more than just an offset. A time zone includes rules for Daylight Saving Time and other anomalies. Use proper time zone names, never 3 or 4 letter codes like EST or IST.
Other Formats
You can apply many other formats:
Built-in ISO 8601 formatters
Built-in localized (short, medium, long, and full formats, Locale-sensitive)
Custom specified by you.
For example, if you want only the date portion without the time-of-day in your String representation, call ISODateTimeFormat.date() to access a built-in formatter.
Example code in Joda-Time 2.8.
String output = ISODateTimeFormat.date().print( dateTime ); // Format: yyyy-MM-dd
Search StackOverflow for hundreds of other Questions and Answers about formatting date-time values.

How can I shift timezone of Date object created in local timezone to target timezone in GWT client?

How can I shift timezone of Date object created in local timezone to target timezone?
Here is what I need. I want web-client to pick a date using DatePicker but resulting Date object should look like as if it was picked in another timezone. Since there is no way to tell DatePicker to do that I have to manually shift date.
For example it's Apr 6th 2012 2:42AM in California right now. Created Date will be in UTC-7 timezone. I want to have Date object with Apr 6th 2012 2:42AM in Europe/Moscow timezone.
Here is I do it right now:
final TimeZoneConstants constTz = GWT.create(TimeZoneConstants.class);
final TimeZone timeZoneMsk = TimeZone.createTimeZone(constTz.europeMoscow());
final TimeZone timeZoneCali = TimeZone.createTimeZone(constTz.americaLosAngeles());
Date curTime = new Date();
DateTimeFormat dateTimeFormat = DateTimeFormat.getFullDateTimeFormat();
Date mskTime = new Date(curTime.getTime() - (curTime.getTimezoneOffset() - timeZoneMsk.getStandardOffset()) * 60 * 1000);
String strLocal = dateTimeFormat.format(curTime, timeZoneCali); // Friday, 2012 April 06 02:42:59 Pacific Daylight Time
String strMsk = dateTimeFormat.format(mskTime, timeZoneMsk); // Friday, 2012 April 06 02:42:59 Moscow Standard Time
There are two problems with this method:
If you ask me it looks pretty bizarre.
Timezone in mskTime is still -0007. I wonder if it can cause any problems in future when I deserialize this object from Google App Engine datastore.
Or should I just produce string with full date of local Californian time, replace timezone in string and then generate new Date by calling DateTimeFormat.parse() ? It looks pretty hacky too...
Also what do you think of JodaTime for GWT ? Is it stable enough for production ?
Your code looks about right. Using DateTimeFormat.parse might make the intention clearer to a casual reader. It's not very often that you are given timezones A and B and one Date object, and you have to produce a new Date object that, when formatted in B, has the same time as the original when formatted in A.
Timezone in mskTime is still -0007. I wonder if it can cause any problems in future when I deserialize this object from Google App Engine datastore.
No, there can be no problems. Remember that a Date object represents a universal point in time not bound to a timezone. When it's April 6 14:40 in Moscow, it's April 6 03:40 in California, so the Date objects are equal.