Training, Open Source computer languages
PerlPHPPythonMySQLApache / TomcatTclRubyJavaC and C++LinuxCSS 
Search for:
Home Accessibility Courses Diary The Mouth Forum Resources Site Map About Us Contact
Python, Lua and Tcl - public course schedule [here]
Private courses on your site - see [here]
Please ask about maintenance training for Perl, PHP, Java, C, C++, Ruby, MySQL and Linux / Tomcat systems
Parsing date & times from strings to long

Posted by Custard (Custard), 19 April 2004
Hello all, I hope you are all well.

I have a little problem with the following piece of code.

What is supposed to happen is that it accepts two fields from an XML record called Start_Time and Start_Date, parses them in to Java Date objects, then retrieves the times in milliseconds and adds them to get a single (long) millisecond time which I can use.

The problem is that when I call Date.valueOf.. on the string date, the value returned is 1 hour older than it ought to be.  
I had the same problem with the time too causing the result to be two hours too old. I fixed this by parsing the time myself.
The java documentation suggests that Date will always return and parse times relative to GMT.
What appears to be happening is that the incoming date is assumed to be something else like BST, then converted to GMT.

Here's the code snippet.  (startTime is long btw.)
                       // Convert from JDBC Time & Date
                       // There is some peculiarity with Date that I just don't understand, whereby a discrepancy of -1 Hour
                       // occurs between parsing the date in, and the resulting time in millis.
                       // I'm sure it must have something to do with TimeZone, but the Data docs insist that all times
                       // are relative to 1/1/1970 GMT -- B.
                       java.sql.Date date = java.sql.Date.valueOf(  XMLhelper.getTagValue(msgPayloadRoot, "Start_Date", 0));
                       // Parse the time in avoiding Date
                       String time[]=XMLhelper.getTagValue(msgPayloadRoot, "Start_Time", 0).split(":") ;
                       long millis;
                       millis=Integer.parseInt( time[0] ) * 3600;
                       millis+=Integer.parseInt( time[1] ) * 60;
                       millis+=Integer.parseInt( time[2] );
                       // Add the two millisecond values to get datetime in millis
                       startTime = date.getTime() + millis;

Any good ideas how I can parse this date without it correcting it for me?

Oh, yes, here are some example input data..
Start_Date is "2003-10-08"
Start_Time is "12:40:08"



Posted by admin (Graham Ellis), 20 April 2004
Yikes ... I wish I had longer to look at this  

Silly question - is the clock on the server set correctly, or does it just appear to be correct?  In other words, I could writing this at 10:50 and the clock says 10:50 .... but that might NOT be correct - if the clock has been set in GMT and that's what it's reporting, it's actually one hour out.  Any calculations on time will result in errors ...

Posted by Custard (Custard), 20 April 2004
I know it's a long one, sorry.

What I want to do is just parse a date & time (GMT) into a millisecond value (GMT relative to the epoch 1/1/70).

In Perl, I would have just used POSIX::mktime to create a time_t number, and that would be correct.  Java's Date seems to do a mysterious conversion.
If it's to do with whatever the server's time is set to, then that's very annoying.  I can't find a way to set Date's timezone to GMT either. Almost everything I try has been deprecated.

Anyway, thanks for the suggestion.
I'm finishing on this project tomorrow anyway.  (Off to do some more Perl, which will be a welcome relief).



Posted by admin (Graham Ellis), 21 April 2004
Ah ... I think you're finished by now.  This has been a mad week here and I've not had my usual time to stop by (Graham adds and then deletes a comment about people changing data file formats and not telling me -  the recipient ) At least it sounds like you have a work-around in place!

This page is a thread posted to the opentalk forum at and archived here for reference. To jump to the archive index please follow this link.

You can Add a comment or ranking to this page

© WELL HOUSE CONSULTANTS LTD., 2018: Well House Manor • 48 Spa Road • Melksham, Wiltshire • United Kingdom • SN12 7NY
PH: 01225 708225 • FAX: 01225 793803 • EMAIL: • WEB: • SKYPE: wellho