I have banged my head against this for too long now!
I have a string: 2012-09-27T18:00:00.000-04:00
I have a format: [dateFormatter setDateFormat:#"yyyy-MM-dd'T'HH:mm:ss'Z'"];
I get a null result converting the string.
Can someone help with the correct date format?
According to the documentation for NSDateFormatter:
The format string uses the format patterns from the Unicode Technical Standard #35. The version of the standard varies with release of the operating system:
Formatters in OS X v10.8 and iOS 6.0 use [version tr35-25].
Following that link:
s 1..2 12 Second. Use one or two for zero padding.
In other words, s for seconds means only the integral part.
But right underneath that, there's:
S 1..n 3456 Fractional Second - truncates (like other time fields) to the count of letters. (example shows display using pattern SSSS for seconds value 12.34567)
Then, the reason you aren't matching the timezone is that you're quoting the Z, so it matches a literal Z rather than a timezone format.
To match the ISO8601 timezone format you're seeing, the same documentation says you want ZZZZZ.
So, it looks like, at least for 10.8/iOS 6, you want:
[dateFormatter setDateFormat:#"yyyy-MM-dd'T'HH:mm:ss'.'SSSZZZZZ"]
For earlier versions, you've got the links to the docs; you should be able to figure it out now.
Testing this (in Python, to save a few lines of code):
>>> import Cocoa
>>> df = Cocoa.NSDateFormatter.alloc().init()
>>> df.setDateFormat_("yyyy-MM-dd'T'HH:mm:ss'.'SSSZZZZZ")
>>> print df.dateFromString_(2012-09-27T18:00:00.000-04:00')
2012-09-27 22:00:00 +0000
Related
I have a csv, and one column is date, format dd/mm/yyyy.
I read it using z=pd.read_csv('property_scrape.csv')
My raw data is:
After I read it in, some of the values are kept in the format I downloaded (dd/mm/yyyy), while somewhere in the middle, the dates are converted to yyyy-mm-dd:
27 01/10/2019
28 01/10/2019
29 01/10/2019
...
21092 2020-08-22
21093 2020-08-22
21094 2020-08-22
Name: Date, Length: 21122, dtype: object
Does anyone know why this happens?
Also, is there a way to ensure that this date column is always read the correct/constant way?
The problem is Pandas samples the first row and thinks it is MM/DD/YYYY instead of DD/MM -- there isn't a real way to know this. Then later when it finds 22, which not a valid MM it defaults to object/string.
You can add flag infer_datetime_format=False and it should read as strings then you can parse it -- you can pass a lambda to read_csv as well, not sure if an easier way to just pass a format string -- see article article dsexchange 34357
I have inherited some code and am very new to VB.
The code is basically being fed decimal values, these are being converted into the Hex equivalent and (I think) the Format function is being used to make sure only 2 characters (i.e. a byte) are being used in another string.
The problem is this, when the Format function encounters a Hex value that Ends in an 'A', it seems to convert the string into a time format of some sort.
Example:
"4A" converts to 04:00:00
"7A" converts to 07:00:00
Here's the relevant code snippet:
Format("4A")
In the actual code I'd get a "00", as the function has the following optional additions:
Format("0A","00")
I'm assuming the "A" is some special character.
Anybody have an idea around this quirk? Thanks in advance!
A is being interpreted as AM just as P would be PM and output 16:00.
Format() is likely not the correct thing to use here, it would only pad as you want it to if the input were a number.
Better to pad after you convert the base:
hexa = Hex$(i)
If (i < 16) Then hexa = "0" & hexa
When I use server.log or request.log I see two numbers appear at the beginning of each line, what exactly are these two numbers?
server.log(['info'], 'hello world');
Output:
151230/205853.557, [log,info], data: hello world
I'm assuming this is a process id and a timestamp? "151230/205853.557" How do I interpret these numbers?
This is the default Date/Time output format of the GoodConsole reporter for Good.
It can be changed by setting the format option:
From the docs:
format - MomentJS format string. Defaults to 'YYMMDD/HHmmss.SSS'.
So 151230/205853.557 means 30th December 2015 at 20:58:33 and 557ms.
I am having an issue trying to parse an Atom RFC 3339 date coming from a feed. Is is coming in is form: #"2014-07-21T11:36:05-05:00" and the following formats fail to parse it... any help?
[dateFormatter setDateFormat:#"yyyy'-'MM'-'dd'T'HH':'mm':'ssZZZ"];
[dateFormatter setDateFormat:#"yyyy'-'MM'-'dd'T'HH':'mm':'ss.SSSZZZ"];
[dateFormatter setDateFormat:#"yyyy'-'MM'-'dd'T'HH':'mm':'ss"];
[dateFormatter setDateFormat:#"yyyy'-'MM'-'dd'T'HH':'mm':'ss.ZZZZ"];
The format you need is
yyyy-MM-dd'T'HH:mm:ssZZZZZ
The five Z pattern is a recent-ish addition to the formatting library that handles exactly this time zone format.
(Despite Apple's Technical Q&A 1480 on this topic (and the identical code in the date formatting guide), the only item in the format string that needs to be escaped with apostrophes is the T -- Unicode Technical Standard #35, which governs the format strings, says that only ASCII letters, a-z and A-Z, are reserved. It also says, however, that punctuation may be used in the future, so you can quote the colons and hyphens if you like.)
I've read through a lot of examples, but the problem I'm facing is the date I'm getting doesn't have leading 0's and all the objective-c stuff I've found has them. So I need to take the date:
4/9/2012 1:30 PM
And determine if it is today. My place was to either grab today's date and compare it to the first part of that string, but as I said before I can't find anyway to make a date in objective c without leading 0's. I'm hoping to avoid parsing that string manually to add leading 0's.
Use an NSDateFormatter object
[dateFormatter setDateFormat:#"h:mm a"];
if you want 0's
[dateFormatter setDateFormat:#"hh:mm a"];
I think that using the single M option for your date format string will allow it to parse a single digit month value:
The possible date formats are specified here
#ynistersix answer is correct. In Data Formatting Guide, they said that NSDateFormatter follows http://unicode.org/reports/tr35/tr35-dates.html
h 1..2 11 Hour [1-12]. When used in skeleton data or in a skeleton
passed in an API for flexible date pattern generation, it should match
the 12-hour-cycle format preferred by the locale (h or K); it should
not match a 24-hour-cycle format (H or k). Use hh for zero padding.
This is consistent with most other languages. Like .NET
"h" The hour, using a 12-hour clock from 1 to 12.
2009-06-15T01:45:30 -> 1
2009-06-15T13:45:30 -> 1
"hh" The hour, using a 12-hour clock from 01 to 12.
2009-06-15T01:45:30 -> 01
2009-06-15T13:45:30 -> 01