Confused with the use of General time zone('z'). Joda is failing in below sample code. Can somebody help me to understand why the behavior is like this? How can I parse a date in differnt timezone using this format in Joda?
public static void main(String[] args) throws ParseException {
SimpleDateFormat sdf = new SimpleDateFormat("yyyy.MM.dd G 'at' HH:mm:ss z");
System.out.println(sdf.parse("2019.09.17 AD at 15:29:00 IST"));
DateTimeFormatter pattern = DateTimeFormat.forPattern("yyyy.MM.dd G 'at' HH:mm:ss z");
DateTime dateCtxParamDateTimeObj = pattern.parseDateTime("2019.09.17 AD at 15:29:00 IST");
System.out.println(dateCtxParamDateTimeObj.toDate());
}
Output
Tue Sep 17 15:29:00 IST 2019
Exception in thread "main" java.lang.IllegalArgumentException: Invalid format: "2019.09.17 AD at 15:29:00 IST" is malformed at "IST"
at org.joda.time.format.DateTimeFormatter.parseDateTime(DateTimeFormatter.java:945)
Edit: You need to tell Joda-Time what you mean by IST
Thanks go to HarryQ, who pointed me here to where this is documented.
DateTimeUtils.setDefaultTimeZoneNames(Collections.singletonMap(
"IST", DateTimeZone.forID("Europe/Dublin")));
DateTimeFormatter pattern = DateTimeFormat.forPattern("yyyy.MM.dd G 'at' HH:mm:ss z");
DateTime dateCtxParamDateTimeObj = pattern.parseDateTime("2019.09.17 AD at 15:29:00 IST");
System.out.println(dateCtxParamDateTimeObj);
The output from this snippet is:
2019-09-17T15:29:00.000+01:00
Lowercase z in a format pattern string works differently when formatting and when parsing in Joda-Time. Joda-Time can format time zone names for all available time zones, but with default settings it can only parse a few back. Which it can parse is controlled by the default time zone names of the DateTimeUtils class. It comes with a map of 10 time zone abbreviations as documented in the DateTimeUtils.getDefaultTimeZoneNames method (link at the bottom): CST, MDT, GMT, PST, PDT, UTC, EDT, CDT, EST and MST. We can substitute with a different map. What I am doing above is substituting with a map of just one abbreviation for the illustration. This risks breaking other code, so a better approach for most purposes would be to build a map containing both the abbreviations that were there before and that or those that we want to be able to parse too.
The map I provided above assumes that IST is for Irish Summer Time (and on September 17, 2019, Ireland was using summer time (DST)). You hardly meant Israel Standard Time because Israel too used summer time, IDT. A third likely understanding is India Standard Time:
DateTimeUtils.setDefaultTimeZoneNames(Collections.singletonMap(
"IST", DateTimeZone.forID("Asia/Kolkata")));
2019-09-17T15:29:00.000+05:30
You notice that we now get offset +05:30 instead of +01:00, so a different point in time. The ambiguity may also be the reason why Joda-Time refuses to make its own assumption about what you intended and therefore needs us to tell it before it can parse the string.
Original answer
It’s a documented limitation in Joda-Time. From the documentation of DateTimeFormat:
Zone names: Time zone names ('z') cannot be parsed.
Also note that IST and many other time zone abbreviations are ambiguous, so if there is any way you can avoid parsing one, by all means do avoid it. IST may be for Irish Summer Time, Israel Standard Time or India Standard Time, and there’s no guarantee which of them you get, or if you may even get Iceland Standard Time.
If you insist, one possible solution is to follow the advice from the Joda-Time homepage:
Note that Joda-Time is considered to be a largely “finished” project.
No major enhancements are planned. If using Java SE 8, please migrate
to java.time (JSR-310).
The DateTimeFormatter class of java.time (the modern Java date and time API) will attempt to parse a time zone abbreviation. Good luck.
Links
Joda-Time
Documentation of DateTimeUtils.getDefaultTimeZoneNames()
Related question: Why Joda DateTimeFormatter cannot parse timezone names ('z')
Documentation of DateTimeFormat
Joda-Time homepage
SO user HarryQ, who in comments under my answer to this duplicate question pointed me to the documentation of Joda-Time’s default time zone names.
Others
My answer here shows how to control the interpretation of IST while parsing when using java.time.
Related
I need to map IANA/Olson timezone id to abbreviations, like EST, PST, etc.
I understand that this is not 1-to-1 mapping and that, for example, for EST there are quite a bunch of IANA timezones.
Is there some kind of database/mapping I can use for this?
PS: JavaScript solution is preferable, but any info that could help me to build this mapping (IANA timezone id -> abbreviation) is appreciated.
The IANA TZDB source data does have abbreviations already, but they have to be computed for the date in question. You can see it in the example data here, in the Zone.FORMAT and Rule.LETTER/S columns.
Since time zone abbreviations like CST can be ambiguous, it is only recommended you use them for display to a human. Never attempt to use them going the other direction, because only a few will be recognized by most implementations, and they tend to be valid only for the USA.
Since you asked for code that could do this for you, look at the bottom half of the code in my answer of how to do this using Noda Time in .Net. (The top half is about translating from a Windows zone to an IANA zone first, which you don't need.)
You could look at one of the several TZDB libraries for JavaScript, but I'm not sure if any directly expose the abbreviation data or not. Besides, that's a bit heavy for something so small.
In java with joda-time, we can get time-zone abbreviation from iana id as below
DateTimeZone dz = DateTimeZone.forID("America/New_York");
String tzid = dz.getShortName(DateTimeUtils.currentTimeMillis());
//tzid will be 'EST'
String longerTimeZoneName = dz.getName(DateTimeUtils.currentTimeMillis());
//longerTimeZoneName will be 'Eastern Standard Time'
I have an ISO-8601 datetime stamp, and need to convert it into local time in GMT. What is the way to do it in Ruby on Rails? I have '1325233011', and need to convert it into local time in GMT standards.
I think what you're asking for is a locale time in GMT+5.
Given an ISO timestamp, 1325233011
When I convert this to a locale-based date/time
Time.at(1325233011) => '2011-12-30 03:16:51 -0500'
Take a look at the ruby-docs, http://www.ruby-doc.org/core-1.9.3/Time.html for more information. Ruby has robust Time and Date classes with many helper utilities. My machine is configured for GMT-5 so it returns the local time. It's easy to change the way timezone settings are interpreted in your program, but that's for another day. Hope this helps!
From Collegue's help got it
Time.at(1325233011).to_datetime
For Iso-8601:
Time.at(1325233011).to_datetime.iso8601
For verification of time correct conversion and comparision use this link
http://coderstoolbox.net/unixtimestamp/
What is the correct format to be used for Edm.Time ?
I see in the protocol document the format for DateTime and DateTimeOffset as follows:
Datetime : "yyyy-MM-dd'T'HH:mm:ss.fff"
DateTimeoffset : "yyyy-MM-dd'T'HH:mm:ss.fffZ"
I did check the protocol here : http://www.w3.org/TR/xmlschema-2/ but could not get the formatting to be used for Edm.Time.
Currently we are using XmlConvert.ToString to convert the time span value to a string representation.
Is there any specific representation that OData recommends for Timespan ?
The formats should be reasonably well documented here, which points you to this link (in the case of Edm.Time).
From XML Schema 2:
3.2.8.1 Lexical representation
The lexical representation for time is the left truncated lexical
representation for dateTime: hh:mm:ss.sss with optional following time
zone indicator. For example, to indicate 1:20 pm for Eastern Standard
Time which is 5 hours behind Coordinated Universal Time (UTC), one
would write: 13:20:00-05:00. See also ISO 8601 Date and Time Formats
(§D).
Note that time-and-date-land have had their issues over the years. The date format varies based upon payload format and version. For instance, JSON Verbose used the /Date(...)/ format for OData v2, but changed to ISO 8601 in OData v3 (much to the collective relief of anyone who doesn't have to implement an OData server and care about all these nuances). This is similar to the struggles that the ASP.NET stack has gone through: http://www.hanselman.com/blog/OnTheNightmareThatIsJSONDatesPlusJSONNETAndASPNETWebAPI.aspx.
Any one know how to convert UTC time to CST time using joda date time api ?
My code is something like this.
DateTimeZone zone = DateTimeZone.forID("CST");
DateTime mstTime = utcDateTime.toDateTime(zone);
Api says 'The datetime zone id CST is not recognised'
Short time-zone ids like "CST" are unclear and ambiguous, so they are not supported. Use a longer form, like "America/New_York".
Some of the three-letter time zones (EST and MST, for example) are included in the default time zone database used by Joda. Others (CST and PST, for example) are not. (See http://joda-time.sourceforge.net/timezones.html for more details.)
The time zone IDs supported by Joda can be obtained by calling org.joda.time.DateTimeZone.getAvailableIDs(), and that set does differ from those returned by java.util.TimeZone.getAvailableIDs().
You can use "CST6CDT" format of joda time.
I have a web service returning JSON data with some date fields but I couldn't recognize the date format to parse this date field.
2010-11-05TNov:10:1288995006 UTC
2010-10-28TOct:37:1288301863 UTC
2010-10-05TOct:33:1286314434 UTC
That is a quite weird timestamp, isn't it.
yyyy[-]mm[-]dd"T"hh":"mm":"ss.nnnnnn"Z" is an ISO standard date format (ISO 8601), which is similar to what appears in the first field of that... but it has what appear to be three field groups, holding what appear to be:
yyyy-mm-dd"T"MMM:??:POSIX-TIMESTAMP UTC
The current time being 1292563122, those would appear to have been generated 3,568,116 seconds (or approximately 41 days) ago.
Hope this helps.
The first epoch (1288995006) translates to
Fri, 05 Nov 2010 22:10:06 GMT
Seems, somebody obfuscated or messed up the human readable month part - 22 would make more
sense than Nov. If you care about the date, I'd suggest you go with the epoch.
Sidenote:
If a date and a time are displayed on the same line, then always write the date in front of the time. If a date and a time value are stored together in a single data field, then ISO 8601 suggests that they should be separated by a latin capital letter T, as in 19951231T235959.
http://www.cl.cam.ac.uk/~mgk25/iso-time.html
I think you are asking the wrong people. You should really be asking whoever is responsible for creating the web service where there documentation is and / or what format the timestamps are supposed to be.
(FWIW - I agree with the consensus that the timestamp format is probably erroneous.)