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.)
Related
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.
Given rails has a convention for most common tasks, is there a format of date/time data that ruby/rails ingests most easily, or which it 'prefers'?
I will have date/time data coming from an external source, and I can choose how it's formatted (but it not be easy to change later). I have researched and found two recommended formats:
A string of format YYYY-MM-DD HH:MM:SS
Unix epoch time (i.e. number of seconds since 1 Jan 1970)
Does rails deal more easily with one of these formats over the other (or is there another convention?)
Additional note: I can see from this talk that it's almost always best to store time in UTC, so I have that much figured out
I would agree that Ruby on Rails default to using the UTC time zone at least in the database.
I do not see a strong convention what time string format Rails prefers, but I would always choose ISO 8601: 'YYYY-MM-DDTHH:MM:SSZ'
I know there a lot of questions along the lines of "how to convert from local to utc", but i think i want something slightly different. Apologies if i am repeating another question (i did search).
I want to convert from one DateTime with Timezone to another DateTime with Timezone, ie:
07/31/2013 18:14:46.676 America/New_York -> 08/01/2013 23:14:46.676 Europe/London
I have looked at TimeWithZone but it seems to assume you set a local timezone and then convert to/from UTC which is not what i want.
Thanks
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/
I'm reading csv data uploaded by users in my Ruby on Rails app. When a user specifies that a particular column has dates(or times), I want to be able to automatically detect the format. This means it can be in American or British formats (any of dd/mm/yy, mm/dd/yy, yyyy-mm-dd, 12 Feb 2010, etc etc)
I have tried parsedate in Ruby but it doesn't work for both American and British dates, unless you specify the format. Is there any way to really do this properly, or am I asking for too much? I don't mind calling a script in another language just for this one task. I'm wondering how it's handled in programs like Excel and Google docs.
Unless the application has a locality I don't know how you can determine this accurately.
What you do know however is that:
There are only 12 months.
Only years can be 4 digits long.
If it contains text then it must be the month.
You could write your own parser with these rules to work it out. It could however (without application locality) misinterpret 05/10/2010 as UK 5th Oct 2010 or US 10th May 2010.
there is little that a program can do to magically determine which type of short date format it is.
If you give a program a date like 09/06/08, it could mean either:
9th of June, 2008, or
6th of September, 2008, or perhaps even
8th of June, 2009.
When Ruby parses dates from string, it will use the default format providers to determine what format the date is in. See the Ruby DateTime class documentation for more info.
I think the best thing to do in your situation would be to try and arrange all of your records in to groups, where each group has one particular format of date. If you yourself can't manually determine the difference between the American and British dates by some criterion, unfortunately a program won't be able to either.
However... if each user is from a specific locale, and you can make the (rather large) assumption that every date they upload in a CSV conforms to their country's date format standards, you could make use of the internationalization API. It should be technically possible to grab that particular user's locale, and then load up the correct i18n data (with the appropriate date formatter), and parse the file using the formatter i18n provides you. Read the Rails Internationalization API guide to get an idea of how you can utilize the i18n API.
I know this is an old post but for archives' sakes I recommend using the Chronic gem for parsing dates/times in CSV imports.
Chronic.parse("8/15/2020") # => 2020-08-15 12:00:00 -0000
Chronic.parse("15/8/2020") # => 2020-08-15 12:00:00 -0000
Chronic.parse("8-15-2020") # => 2020-08-15 12:00:00 -0000
Chronic.parse("8-15-2020 3PM") # => 2020-08-15 15:00:00 -0000
FYI you'll want to tell Chronic to parse in the client's account timezone. Otherwise it will use the globally configured timezone (which is UTC in my example).