Develop Reference

Extracting TimeZone from Mongo Date

I have a date string of the form: "Fri Jun 20 16:14:00 GMT+0530 2014"
As you can see there is TimeZone information in the date (GMT+0530).
But once we store this in MongoDB using mongodb 'date' datatype.
I see it is stored in a format like this:'2014-06-20 10:44:00.470Z'
How can i extract the 'original' Time Zone from this date??
(I am using Java for storing/extracting data from mongo)

The BSON Date data type that MongoDB uses is simply a 64-bit integer count of milliseconds since UTC Jan 1, 1970. So if you want to track a time stamp's original time zone you'd have to store that separately as it's lost when converted to Date.

MongoDB stores dates in ISO 8601 format. There's no straight forward way to convert to it from the Java date format, but here's a similar question, look at the accepted answer, it should give you a clue on how to do this.

C# Ticks convert to java util date; date is 5 hours behind why?

I need help. I have been trying to figure out why java util date is 5 hours behind after converting from C# ticks.
in C#, the date is 6/8/2013 11:02:07 AM, I convert this date into ticks then pass it to java as long.
code snippet:
taken:
- long TICKS_AT_EPOCH = 621355968000000000L;
- long TICKS_PER_MILLISECOND = 10000;
java.util.Date date = new java.util.Date((ctime - TICKS_AT_EPOCH) / TICKS_PER_MILLISECOND);
Now java util date is Sat Jun 08 06:02:07 CDT 2013
Notice that the hour is 5 hours difference.
Any suggestions why?

You are constructing a java.util.Date based on milliseconds since 1/1/1970 UTC. You appear to be correcting from the fact that .net's System.DateTime.Ticks are based on 1/1/0001 and are 10,000 ticks to a millisecond. That is correct, but you have forgotten to adjust to UTC.
In .Net, the value coming from DateTime.Ticks is highly dependent on the DateTime.Kind property. There are three possible kinds of DateTime values.
DateTimeKind.Utc - This kind means that the value represents UTC time. It usually comes from a call to DateTime.UtcNow, but can also be constructed directly, and often is. For example, you might be retrieving UTC times from a database. You can feed the ticks from here directly into your conversion, and it will work.
DateTimeKind.Local - This usually comes from a call to DateTime.Now. The values are representative of the local time zone. You will need to convert to UTC before checking the ticks. You can do the following:
DateTime dt = DateTime.Now;
int utcTicks = dt.ToUniversalTime().Ticks;
Be aware that if the time happens during a daylight saving "fall-back" style transition, the result might be incorrect. The DateTime class has no idea about time zones. It just reflects the current local clock. If the value in dt is ambiguous, ToUniversalTime() will assume that the value is representative of standard time, even if you just retrieved it while in daylight time. This is just one of the many confusing and probablematic aspects of DateTime in .net.
DateTimeKind.Unspecified - This is the most common kind of DateTime you will encounter, and usually comes from DateTime.Parse() or a constructor like new DateTime(...). Unfortunately, there is nothing in here that will tell you about the time zone these dates are representative of. You can still try calling .ToUniversalTime(), but the framework will make the assumption that these times are representative of your local time zone, as if the kind was Local. That assumption could be completely wrong, depending on how you sourced the data. There really is no safe way to transform an Unspecified DateTime to a UTC value (ticks or otherwise).
There are some solutions, such as using DateTimeOffset instead of DateTime, or using the Noda Time library instead of the built-in types. You can read more about these problems here and here.

The time is not 5 hours behind, it's exactly the same time. The problem is with the way you print it.
You need to tell C# and Java to use the same time-zone when converting the date to string. One of them is using UTC and the other CDT.

java.util.date automatically corrects for your time zone. See this question: How to set time zone of a java.util.Date?

The ctime is UTC (Universal Coordinated Time), which is a time standard referenced to Greenwich. You're expressing your time in Central time. There's your difference.

Passing javascript date to java

I store dates on server side in UTC timezone.
When client (browser) wants to pass some date to server it sends date like
"Tue Jan 03 2012 16:50:32 GMT+0400 (Russian Standard Time)"
Is this format standard across all browsers?
If 1. is false, how can I redefine the Date format function? Is this a good practice?
How can I convert JS Dates to a UTC java.util.Date with java.text.SimpleDateFormat?
UPDATE
I thought that passing date as formatted string (with timezone part) will cause less headache since I shouldn't bother to convert dates to UTC on client side. So I avoid any date conversions in JS code.

You should send the number of milliseconds since epoch (1 Jan 1970 UTC) that is available via the + prefix operator as in +new Date(2012, 0, 1).
Sending anything with a timezone requires both machines to have the same timezone definitions which means you will likely end up with subtle bugs where two dates occurred in one order on one machine but in a different order on another. You can eliminate that whole class of bugs by using the millis since epoch representation.
To answer your questions:
Is this format standard across all browsers?
Date.prototype.toString and toUTCString are both implementation dependent but toISOString is reliable.
http://es5.github.com/#x15.9.5.43
15.9.5.43 Date.prototype.toISOString ( ) # Ⓣ Ⓡ
This function returns a String value represent the instance in time represented by this Date object. The format of the String is the Date Time string format defined in 15.9.1.15. All fields are present in the String. The time zone is always UTC, denoted by the suffix Z. If the time value of this object is not a finite Number a RangeError exception is thrown.
15.9.1.15 Date Time String Format # Ⓣ Ⓔ Ⓑ
ECMAScript defines a string interchange format for date-times based upon a simplification of the ISO 8601 Extended Format. The format is as follows: YYYY-MM-DDTHH:mm:ss.sssZ
Whereas http://es5.github.com/#x15.9.5.2 says
15.9.5.2 Date.prototype.toString ( ) # Ⓣ Ⓡ
This function returns a String value. The contents of the String are implementation-dependent, but are intended to represent the Date in the current time zone in a convenient, human-readable form.
http://es5.github.com/#x15.9.1.15
15.9.5.42 Date.prototype.toUTCString ( ) # Ⓣ Ⓡ
This function returns a String value. The contents of the String are implementation-dependent, but are intended to represent the Date in a convenient, human-readable form in UTC.
NOTE The intent is to produce a String representation of a date that is more readable than the format specified in 15.9.1.15. It is not essential that the chosen format be unambiguous or easily machine parsable. If an implementation does not have a preferred human-readable format it is recommended to use the format defined in 15.9.1.15 but with a space rather than a “T” used to separate the date and time elements.

I don't know whether this format is standardized for all browsers.
But you could use the getTime() function in JavaScript which returns the milliseconds since 1 January 1970 00:00:00 UTC and initializes the Java Date object with this value.

You could send the data in UNIX time format, maybe?

what is the difference betwen timestamp in java and php?

I have a java file that write records to the DB and time stamps
I have another php file that reads that records..
unfortunately After converting the time stamp to dates I got a wrong dates ??
what is the problem !!!

Java uses a timestamp which is milliseconds from the epoch. PHP uses the standard unix timestamp which is seconds from the epoch.
I believe both use the same epoch of Jan. 1, 1970 00:00:00 UTC

PHP uses the UNIX epoch, I suspect Java uses a different epoch.
EDIT: I was way off, turns out PHP uses seconds, java uses miliseconds. So multiply by 1000 or divide by 1000 depending on which way you're converting.

I think the problem is you're retrieving a DATETIME or TIMESTAMP column or such that has been stored and screwing up the conversion. Try this:
$phpdate = strtotime( $dateFromDb );
echo date("F j, Y, g:i a", $phpdate);

Best way to extract a timezone from a mail Date header in Java?

I need to store the timezone an email was sent from. Which is the best way to extract it from the email's 'Date:' header (an RFC822 date)? And what is the recommended format to store it in the database (I'm using hibernate)?

I recommend you use Mime4J.
The library is designed for parsing all kinds of email crap.
For parsing dates you would use its DateTimeParser.
int zone = new DateTimeParser(new StringReader("Fri, 27 Jul 2012 09:13:15 -0400")).zone();
After that I usually convert the datetimes to Joda's DateTime. Don't use SimpleDateFormatter as will not cover all the cases for RFC822.
Below will get you the Joda TimeZone (from the int zone above) which is superior to Java's TZ.
// Stupid hack in case the zone is not in [-+]zzzz format
final int hours;
final int minutes;
if (zone > 24 || zone < -24 ) {
hours = zone / 100;
minutes = minutes = Math.abs(zone % 100);
}
else {
hours = zone;
minutes = 0;
}
DateTimeZone.forOffsetHoursMinutes(hours, minutes);
Now the only issue is that the Time Zone you will get always be a numeric time zone which may still not be the correct time zone of the user sending the email (assuming the mail app sent the users TZ and not just UTC).
For example -0400 is not EDT (ie America/New_York) because it does not take Daylight savings into account.

Probably easiest to parse with JodaTime as it supports ISO8601 see Date and Time Parsing and Formatting in Java with Joda Time.
DateTimeFormatter parser2 = ISODateTimeFormat.dateTimeNoMillis();
System.out.println(parser2.parseDateTime(your_date_string));
Times must always be stored in UTC (GMT) with a timezone - i.e. after parsing convert from the timezone to GMT and remove daylight savings offset and save the original timezone.
You must store the date with the timezone after converting to UTC.
If you remove or don't handle the timezone it will cause problems when dealing with data that has come from a different timezone.

Extract the data from the header using some sort of substring or regular expression. Parse the date with a SimpleDateFormatter to create a Date object.

The timezone in the email will not show in which timezone it was send. Some programs use ever UTC or GMT. Of course the time zone is part of the date time value and must also be parse.
Why do you want know it.
- Do you want normalize the timestamp? Then use a DateFormat for parsing it.
- Do you want detect the timezome of the user that send the email? This will not correctly work.

It looks like you already mentioned this in one of your comments, but I think it's your best answer. The JavaMail library contains RFC822 Date header parsing code in javax.mail.internet.MailDateFormat. Unfortunately it doesn't expose the TimeZone parsing directly, so you will need to copy the necessary code directly from javax.mail.internet.MailDateParser, but it's worth taking advantage of the careful work already done.
As for storing it, the parser will give you the date as an offset, so you should be able to store it just fine as an int (letting Hibernate translate that to your database for you).