We Keep Coding

Time difference between Dates Java?

I have been using the legacy Date API to calculate time difference between two times in yyyyMMdd'T'HHmmss format.
Client sets the requestExpirationTime attribute in request and server has a validation check to ensure that "RequestExpirationTime is not before current system time".
Client:
SimpleDateFormat simpleDateFormat = new SimpleDateFormat("yyyyMMdd'T'HHmmss");
Timestamp originatingTimestamp = new Timestamp(new Date().getTime());
// duration is offset 5minutes for exmaple
Timestamp requestExpirationTimestamp = new Timestamp(originatingTimestamp.getTime() + duration);
request.setRequestExpirationTimestamp(simpleDateFormat.format(requestExpirationTimestamp));
Server:
try {
Date systemTime = new Date();
SimpleDateFormat sdf = new SimpleDateFormat("yyyyMMdd'T'HHmmss");
String ret = request.getRequestExpirationTimestamp();
if (ret != null) {
Date requestExpirationTimestamp = sdf.parse(ret);
if (requestExpirationTimestamp.before(systemTime)) {
logger.info("Request timedout: RequestExpirationTime is before current system time");
}
}
}
This code is giving issues as the systemTime on server comes in IST (Indian Standard Time) and client can send in any UTC/IST.
I have now moved to Java 8, so I can leave the legacy Date Api in Java.
How can I ensure such Timezone issues don't come in my code ? I tried setting timeZone in
SimpleDateFormat on the server but the new Date() is behaving differently on different servers.
Any help is appreciated.

When the client sends time that is not in UTC, for example India Standard Time (IST), and the server doesn’t know which time zone the client used, then there is nothing the server can do to make it work correctly. Instead I suggest that you make sure that the client sends time in UTC always.
Client
Make sure you always send time in UTC:
DateTimeFormatter formatter = DateTimeFormatter.ofPattern("uuuuMMdd'T'HHmmss");
String requestExpirationTime = OffsetDateTime.now(ZoneOffset.UTC)
.plusMinutes(5)
.format(formatter);
System.out.println(requestExpirationTime);
Example output from running just now:
20200506T183409
Server
Now the server knows the time is in UTC. I am assuming that it is using a formatter identical to the one the client used.
OffsetDateTime dateTime = LocalDateTime.parse(requestExpirationTime, formatter)
.atOffset(ZoneOffset.UTC);
OffsetDateTime systemTime = OffsetDateTime.now(ZoneOffset.UTC);
if (dateTime.isBefore(systemTime)) {
System.out.println("Request timedout: RequestExpirationTime is before current system time");
} else {
System.out.println("OK");
}
OK
Tip
You may append Z to your timestamp string to make it explicit that it is UTC. It might prevent some mistakes further down the road.
20200506T183409Z

Inconsistent Timezones with GMT set in parsing LDAP date and Timestamps

I'm parsing the times from AD. There are two formats, i.e., YMD LDAP timestamps for whenCreated, whenChanged, 18-digit LDAP/FILETIME timestamps for lastLogonTimestamp, pwdLastSet, etc. Because I need to analyze the data upon the time. It makes sense to get local time. Here are the two functions that I wrote to parse the two different formats. The calculation in the second function I referenced from Convert 18-digit LDAP Timestamps To Human Teadable Date Using Java
public static String parseLdapDate(String ldapDate) {
String[] parts = ldapDate.split("[.]");
String dateTimePart = parts[0]; //take the date string before .0Z
SimpleDateFormat sdf = new SimpleDateFormat("yyyyMMddhhmmss");
sdf.setTimeZone(TimeZone.getTimeZone("GMT")); //Z means UTC time, to the local timezone
SimpleDateFormat formatter = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
try {
Date tempDate = sdf.parse(dateTimePart); //parse the string to a date
return formatter.format(tempDate); //format it as what we want
} catch (ParseException ex) {
System.out.println("Parsing LDAP Date exception \n");
ex.printStackTrace();
}
return null;
}
public static String parseLdapTimestamp(String ldapTimestamp) {
long nanoseconds = Long.parseLong(ldapTimestamp); // 100 nanoseconds
long mills = (nanoseconds/10000000); // To seconds
long unix = (((1970-1601)*365)-3+Math.round((1970-1601)/4))*86400L;
long timeStamp = mills - unix;
Date date = new Date(timeStamp*1000L); // To milliseconds
SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
sdf.setTimeZone(TimeZone.getTimeZone("GMT"));
return sdf.format(date);
}
I have an example 20150520143936.0Z, which is converted to "2015-05-20 16:39:36".
For the example 131097986571852097, it is converted to "2016-06-07 18:44:17", while http://www.epochconverter.com/ldap tells me that it's the GMT time and the local time is "2016-06-07 20:44:17". I will get the local time if I comment the code of setting timezone.
So now I'm confused, sdf.setTimeZone(TimeZone.getTimeZone("GMT")); gives me local timezone or the universal time. I was thinking if AD stores whenCreated in the universal time, lastLogonTimestamp in local time. But in the functions I parse them as strings. There is no symbol about the timezone. If I comment this sentence in the second function, will I get local time for both attributes when I access an LDAP Directory in another place.

In the second case, you're constructing a Date and then telling it to format that date in UTC - whereas in the first case, you're parsing it in UTC, but formatting it in local time. You're already assuming that the timestamp is stored as a number of ticks since the Unix epoch, which is a time zone neutral format.
If the aim is to produce a string representation in local time, then you should remove the sdf.setTimeZone call. I would argue that a parse method should be returning a Date anyway though, rather than a String. Or better yet, return a java.time.Instant...

Incorrect time when converting from DB time to local machine time

In my Oracle DB date is stored in Central Time. My local machine is also in Central time. I am trying to write a Java code so that DB central time can be converted to any local machine time zone. For example if I change my local machine time in Eastern time time from DB will be converted to Eastern time.
Here is Java method which takes date from DB and offset minutes from user browser using JavaScript
private String convertDateToLocal(Date createDate, Long offSetMins) {
DateFormat formatter = new SimpleDateFormat("MM/dd/yyyy hh:mm a", Locale.US);
Calendar calendar = Calendar.getInstance();
calendar.setTime(createDate);
Long dbTimeInMilliSec = createDate.getTime();
Long dbTimeOffSet = (long) (calendar.getTimeZone().getOffset(dbTimeInMilliSec));
Long dbTimeToUTC = dbTimeInMilliSec + (dbTimeOffSet * -1);
Long dbTimeToLocal = dbTimeToUTC - (offSetMins * 60 * 1000);
Date createDateInLocal = new Date(dbTimeToLocal);
return formatter.format(createDateInLocal);
}
Just for reference this is how I am getting offset minutes using JavaScript
var offSetMins= new Date().getTimezoneOffset();
But the issue is even when I have local machine setup to Central time I am seeing time 1hr ahead for days where there is no daylight saving.
DB date (11/26/2014 12:03 PM) is showing as (11/26/2014 01:03 PM) in UI.
Dates in daylight saving time is OK.
DB date (05/20/2015 05:08 PM) is showing as (05/20/2015 05:08 PM) in UI.

I used jsTimezoneDetect in front end and Joda-Time in backend Java code to solve this issue.
JavaScript
var tz = jstz.determine();
var timeZone = tz.name();
//send this timeZone to server
Java Code
private String convertDateToLocal(Date createDate, String timeZone) {
Long dbDate = createDate.getTime();
DateTimeFormatter fmt = DateTimeFormat.forPattern("MM/dd/yyyy hh:mm a zz");
DateTime origDate = new DateTime(dbDate);
DateTime dtTz = origDate.withZone(DateTimeZone.forID(timeZone));
return dtTz.toString(fmt);
}

Try using Timezone class of JAVA.
You need to have two timezone object one for DB Timezone and second one for machine timezone and then you can do the conversions.
hope this helps
Kaushik

Can't retrieve correct time and date from netflow records.

I used jflow-0.3[1] to collect and decode netflow records which I receive from a router.
nettrack.net.netflow.Flow.java class contains the code for decoding necessary data from records received. I called getFirst() function of it which returns "The time in Coordinated Universal Time (UTC) seconds when this data collection period began."[2]. Then I converted it into date time format using following code.
long seconds = getFirst();
long millis = seconds * 1000;
Date date = new Date(millis);
SimpleDateFormat sdf = new SimpleDateFormat("EEEE,MMMM d,yyyy h:mm,a", Locale.ENGLISH);
sdf.setTimeZone(TimeZone.getTimeZone("UTC"));
String formattedDate = sdf.format(date);
System.out.println(formattedDate);
But when I run this I observe weird results for date like Monday,March 2,1970 4:21,PM, Sunday,April 27,2059 4:17,AM,etc. UTC value is also change from very small values like 300 to very large values like 3154137089 which does not make any sense. What is the problem here? how can I solve this?
https://github.com/aptivate/netgraph/tree/master/jflow-0.3
http://www.cisco.com/en/US/docs/net_mgmt/netflow_collection_engine/6.0/tier_one/user/guide/data.html

Android Convert Central Time to Local Time

I have a MySql database that stores a timestamp for each record I insert. I pull that timestamp into my Android application as a string. My database is located on a server that has a TimeZone of CST. I want to convert that CST timestamp to the Android device's local time.
Can someone help with this?

Use getTimeZone.getDefault combined with according to the Android documentation.
public static synchronized TimeZone
getDefault ()
Gets the default time zone. Returns
the default time zone.
So since you know that CST is -6:00 from GMT, and you get a local timezone saying the user is +9:00 (Japan), you'd know to adjust your MySQL DB times by +15 hours (9 - (-6)). Or if they are in Miami (EST, -5), you would adjust by adding one hour (-5 - (-6)). If the are in Portland, Oregon, (PST -8), you would subtract 2 hours (-8 -(-6)).
So really you just need to get the local timezone offset and feed it into the basic equation: TimeZone.getDefault + 6 and you'll know what to add or subtract to your local DB. (+6 since -(-6) always works out to +6).
If I knew the first thing about writing Java, I'd go the extra step and write a bit of sample code, but alas, I'm only smart enough for scripts.
Crude Attempt at Java
I already said I have no idea how to do Java or object oriented anything, right?
Here's a crude attempt from just poking around the Android documentation. Any fine points or simple "Not even close" remarks welcome. Bear in mind that I figured out the right method and class already just from a quick search and I came up with a simple equation for converting the timezone offset for anywhere to CST, so I'm not a dunce, just someone who doesn't know when to leave well enough alone. Anyway, crude attempt:
System now = System.currentTimeMillis (); //Gets current local time in ms
TimeZone local_tz = TimeZone.getDefault(); //Gets current local TZ of phone
tz_offset_gmt = local_tz.getOffset(now)/3600000; // Get Offset in ms, divide by 3600000
tz_offset_cst = tz_offset_gmt + 6; // add offset to 6 to get current TZ offset to CST.
Anywhere close to how to do this in java?

Suppose you have a string of date in CST, parse it with timezone CST and then format it with the default timezone on your android.
String s = "2011-01-01 12:00:00";
DateFormat df = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
df.setTimeZone(TimeZone.getTimeZone("CST"));
Date timestamp = null;
try {
timestamp = df.parse(s);
df.setTimeZone(TimeZone.getDefault());
System.out.println(df.format(timestamp));
} catch (ParseException e) {
e.printStackTrace();
}

can't you simply convert the date with simpleDateFormat?
then you just define the structure of your incoming date like that (df) and transform it to the form you want (df):
private static DateFormat df = new SimpleDateFormat("EEE, d MMM yyyy HH:mm:ss Z");
private static DateFormat df2 = new SimpleDateFormat("dd/MM/yyyy 'at' HH:mm");
public void setyourDate(String yourDate) {
Date date2;
yourDate = getyourDate() + "" + yourDate;
try {
date2 = df.parse(yourDate);
yourDate = df2.format(date2);
} catch (ParseException e) {
}
this.yourDate = yourDate;
}
does it make sense?

This is an old question, but I want to write my answer. Assume, the timestamp you get from SQL is like the following format: yyyy-MM-dd'T'HH:mm:ss
public static Date convertStringToDate(String strDate) {
SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss");
sdf.setTimeZone(TimeZone.getTimeZone("CST"));
return sdf.parse(strDate);
}