The date is coming from an imported xml that gives a 13 digit string (unix epoch time format).
The following snippet causes the resulting column value to be set to 1970-01-01
seconds=msg.time_stamp_long.to_i/1000
time=Time.at(seconds).utc.to_s
msg.time_stamp=time
msg.save
How to get the correct format for a DateTime column?
Time.at(1663681609392 / 1000).to_datetime
or if it's a string
Time.at("1663681609392".to_i / 1000).to_datetime
Be aware that unix time is epoch UTC time. Time and DateTime can get tricky in Ruby and in Rails. Make sure you are getting the time you expect. You may need to look into methods like .in_time_zone
To use your variables from the question:
msg.update(time_stamp: Time.at(msg.time_stamp_long / 1000))
is all you really need. As Max pointed out the DB adapter will handle the rest. But when you go to display or manipulate dates/times in Rails you might want to look into Date, Time, TimeWithZone, DateTime, etc. to understand the options that are out there and how they apply to your use case.
I'm trying to convert a date into a week number, which should be simple, only it's giving back value. Instead of the week number, it says 16/01/1900 00:00:00.
I used =ISOWEEKNUM(C2) and =WEEKNUM(C2, 2) and I tried it without time and in different date formats as well.
Does somebody know how to fix this issue?
Issue is found, the cells of the week numbers had a date format, so I had to convert it into plain text. It works now!
This question already has answers here:
Converting an ISO 8601 timestamp into an NSDate: How does one deal with the UTC time offset?
(6 answers)
Closed 9 years ago.
I have tried and tried and researched and tried again but I cannot format this
The date is:
"2013-08-08T11:10:09-07:00"
I've tried using "yyyy'-'MM'-'DD'T'HH':'mm':'ssZ" and a host of different permutations of this but to no avail. I think perhaps the server is sending the incorrect format of the timezone.
NSDateFormatter *dateFormatter = [[NSDateFormatter alloc] init];
[dateFormatter setDateFormat:#"yyyy'-'MM'-'DD'T'HH':'mm':'ssZ"];
return [dateFormatter dateFromString:[dictionary objectForKey:key]];
Any clues?
Thanks in advance
For the non-localized ISO offset that you're using—e.g., -07:00—you need to use 5 Z characters in your format. So, for the source data given, the correct format string would be:
yyyy-MM-dd'T'HH:mm:ssZZZZZ
While the currently used technical standard doesn't require date and time separators to be escaped, as Jeff mentions in the comments, it's probably not a bad idea to do so, especially if your source date is coming from a server or something. There are discussions on making those replacements, like the letters, that would change for locale-specific date and time separators. It also doesn't hurt to escape them from a technical perspective, it's just harder to read:
yyyy'-'MM'-'dd'T'HH':'mm':'ssZZZZZ
For more information, the current date formatter is based on the Unicode Technical Spec #35. The date and time pattern specifications for #35 can be found at http://www.unicode.org/reports/tr35/tr35-25.html#Date_Format_Patterns
I'm trying to store a time in a date.
In this case 1.5 seconds.
I store the time in the date like this:
NSDateFormatter *dateFormatter = [[NSDateFormatter alloc] init];
[dateFormatter setDateFormat:#"mm:ss.SS"];
[dateFormatter setTimeZone:[NSTimeZone timeZoneForSecondsFromGMT:0.0]];
NSDate *date1 = [dateFormatter dateFromString:#"00:01.50"];
But if I look in the debug area I can see that the value of date1 was set to:
date1 = (NSDate *) 0x1dd32b30 2000-01-01 01:00:01 CET
Could anyone tell me why this is happening?
Because there is a mass of question related to NSDate on SO and they all have the same shade, I will give you a longer answer, probably this can be referred from other questions.
A. There is a common misunderstanding, what a date is: A date is a point on timeline. It does not deal with hours or minutes, it does not deal with days, month, years, it does not deal with timezones.
It is a point on a timeline. Period.
(And internally it is represented by an floating-point number. Is that a surprise?)
B. There is another common misunderstanding, what a date is: Two dates, therefore points on a timeline, are equal, if the have the same value. This does not mean, that they have the same representation. Two times can be equal, even their representation is completly different. (This is, what happened to you.) For a comparison it does not matter, which timezone is in use, expected, $whatever. For a comparison is does not matter, which calendar is in use, expected or $whatever. If it is 11:11 in Cologne, Germany (UTC+1) it is 10:11 in London, England (UTC+0). This is the same time.
A date is earlier if it is on the timeline ahead of another date.
C. So what are these funny things like days, month, timezones and so on?
Since outside a star trek episode a time like 26,182,382,303.127373 would be difficult to understand and to handle, human beings began to give points on the timeline funny names. This representations are not the date. They are representations of the date. It is the same problem with numbers. Do you no this joke?
"There are 10 kind of people: Those, who understand binary numbers and those who doesn't."
The spirit of the joke is, that 10 can be the value of ten, if it is written in decimal notation or it can be the value of two, written in binary notation. Nobody can say, what value "10" denotes unless he knows the numeral system which is used for the representation. Most people assume, that it is in a decimal system, so "10" means ten. This is a popular convention. And this works fine since nearly all over the world adopted that convention. But: "10" can denote two different values. And the other way around, too: The same value can be written with different "strings": 10 in decimal notation is equal to 1010 in binary notation (and is equal to "2+8", sqrt(100), … That is, why it is allowed to write = between them.)
Unfortunaly (no, not really, time has to work locally in an easy way) for time there is no world-wide convention. If somebody writes "11:11" you simply cannot say, what time (remember, it is a point on the timeline) is meant. Probably the person implicitly says, that this is the time in his calendaric system in his timezone. But then you have to know, at which location on the world he is saying that. Taking day, month and so on in account, you probably have to know, what is his religion, because even in one country people of different religions uses different calendars.
Since there is no common world-wide convention on one hand and Mac OS is running on computer systems world-wide, you cannot assume, that a time printed out is written in a notation you expect.
Therefore it is completly, eh, not very intelligent to compare to dates by string. You do not compare dates, you compare strings.
Before you compare a time (including date) you have to transform the representation to a time to the "real" time. You have to add information about the calendar, the representation is written in and the timezone (which is included in the calendar in Cocoa).
In Cocoa you use instances of NSDateFormatter, NSCalendar, NSDateComponents to do this job. If you let NSDateFormatter transform a representation to a time and vice versa, you have to set the calendar. (NSDateFormatter assumes, that the local calendar is choosen, if you do not set one.) It is simply impossible to NSDateFormatter to do any transformation work, if it does not know which calendar to use. And it is simply impossible for you.
Then you can do some calculations with it, the date, the time, the instance of NSDate, including comparison and at least you have to transform it back into a human-readable representation using a calendar.
What you get and let you think, that it is a wrong time, is simply the correct time but in a represenatation you did not expect. (-description always delivers UTC+0).
Trying NSLog on date will return date in GMT format only. So if you want to check if you are getting the correct time or date, convert date to string and NSLog.
NSDateFormatter *dateFormatter = [[NSDateFormatter alloc] init];
[dateFormatter setDateFormat:#"mm:ss.SS"];
[dateFormatter setTimeZone:[NSTimeZone timeZoneForSecondsFromGMT:0.0]];
NSDate *date1 = [dateFormatter dateFromString:#"00:01.50"];
NSString *dateString = [dateFormatter stringFromDate:date1];
NSlog(#"%#",dateString);
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.)