NSDate issue

[cafuni]

Hi, I'm sending to rest server a NSDate object.

if I print print(NSDate())

i get:
2016-01-18 15:35:43 +0000

after conversion with EVReflection i get:

"18/01/16, 16:35:49 CET",

this output is not compliant with standard because back end response is:

Can not construct instance of java.util.Date from String value '18/01/16, 16:35:49 CET': not a valid representation (error: Failed to parse Date value '18/01/16, 16:35:49 CET': Can not parse date "18/01/16, 16:35:49 CET": not compatible with any of standard forms ("yyyy-MM-dd'T'HH:mm:ss.SSSZ", "yyyy-MM-dd'T'HH:mm:ss.SSS'Z'", "EEE, dd MMM yyyy HH:mm:ss zzz", "yyyy-MM-dd"))\n at

[evermeer]

Hi,

You could influence the date formatting in 2 ways. You could set a standard NSDateFormatter by calling the EVReflection.setDateFormatter(theFormat) or you could do the formatting per property by implementing the propertyConverters method.

The current default NSDateFormatter is configured like this:
dateFormatter = NSDateFormatter()
dateFormatter!.dateStyle = .ShortStyle
dateFormatter!.timeStyle = .LongStyle
I think you are seeing the / as a separator because the / is escaped. when the json is generated.
Maybe a different format would be better. I will do some investigation...

[cloudcosmonaut]

Hi Edwin,

I'm running into the same issue. The dateformatter is not using ISO8601/RFC3339 format. I think it should, as it is the standard for transmitting dates over the web.

Any particular reason why you used another format?

BR Hindrik

[evermeer]

I have merged your pull request an pushed version 2.15.2

[cafuni]

i get

Can not construct instance of java.util.Date from String value '1987-04-23T22:00:00.000GMT': not a valid representation (error: Failed to parse Date value '1987-04-23T22:00:00.000GMT': Can not parse date "1987-04-23T22:00:00.000GMT": not compatible with any of standard forms ("yyyy-MM-dd'T'HH:mm:ss.SSSZ", "yyyy-MM-dd'T'HH:mm:ss.SSS'Z'", "EEE, dd MMM yyyy HH:mm:ss zzz", "yyyy-MM-dd"))\n at

[evermeer]

I think the T should be just a space in the dateformatter could you try that?

[cloudcosmonaut]

No, RFC339/ISO8601 dictates the T. See https://www.ietf.org/rfc/rfc3339.txt
Op wo 20 jan. 2016 om 17:18 schreef Edwin Vermeer notifications@github.com

I think the T should be just a space in the dateformatter could you try
that?

—
Reply to this email directly or view it on GitHub
#35 (comment)
.

[evermeer]

I'm not sure what the correct dateFormatter should be. I don't know how I could test the result.

[cloudcosmonaut]

I will take a look at it tomorrow, and implement more formats. The format I
added is mostly used on the web, but there are more within the ISO
standard.

Maybe I could do a check which format is used by doing regex checks. What
are your thoughts on that?
Op wo 20 jan. 2016 om 22:22 schreef Edwin Vermeer notifications@github.com

I'm not sure what the correct dateFormatter should be. I don't know how I
could test the result.

—
Reply to this email directly or view it on GitHub
#35 (comment)
.

[evermeer]

What's wrong with the date from the error you reported above?
You get an error for 1987-04-23T22:00:00.000GMT
If it's not the T between date and time, then maybe there should be a space between the time and timezone.

[rafcabezas]

In my experience RFC3339 is of the form:

(These taken from NSDate+InternetDateTime, MWFeedParser by Michael Waterfall):

// 1996-12-19T16:39:57-0800
[dateFormatter setDateFormat:@"yyyy'-'MM'-'dd'T'HH':'mm':'ssZZZ"]; 

// 1937-01-01T12:00:27.87+0020
[dateFormatter setDateFormat:@"yyyy'-'MM'-'dd'T'HH':'mm':'ss.SSSZZZ"]; 

// 1937-01-01T12:00:27
[dateFormatter setDateFormat:@"yyyy'-'MM'-'dd'T'HH':'mm':'ss"]; 

See http://www.faqs.org/rfcs/rfc3339.html

This might also help: https://github.com/search?l=Objective-C&q=rfc-3339&ref=searchresults&type=Repositories&utf8=%E2%9C%93

None of these include the "GMT" wording.

Hope this helps!

[evermeer]

Ah, I wil do some tests with that this evening and see where the GMT comes from.

[cloudcosmonaut]

It's a less used variates. I'm now implementing about 14 variations.

I'll keep you posted.
Op do 21 jan. 2016 om 15:26 schreef Edwin Vermeer notifications@github.com

Ah, I wil do some tests with that this evening and see where the GMT comes
from.

—
Reply to this email directly or view it on GitHub
#35 (comment)
.

[cloudcosmonaut]

Ok, it took a while. I created a small library which detects different patterns using regular expressions.

@cafuni But now I see your issue is not what parsing dates, but serialising it again to JSON. Is that correct?

@rafcabezas RFC3339 supports more formats then only those. Besides that, the 'T is optional in RFC3339 and the '-' and ':' are optional in both RFC and ISO8601.

[evermeer]

I think that using the following date format is the most complete, readable and according to the RFC:

        dateFormatter = NSDateFormatter()
        dateFormatter!.locale = NSLocale(localeIdentifier: "en_US_POSIX")
        dateFormatter!.timeZone = NSTimeZone(forSecondsFromGMT: 0)
        dateFormatter!.dateFormat = "yyyy'-'MM'-'dd' 'HH':'mm':'ss.SSS ZZZ"

If anyone disagree, then please let me know why a different format should be used. If you have the need for an alternative format, then remember that you still are able to set one using the .setDateFormat function.

The above dateformat is now the active format of version 2.15.5

[cloudcosmonaut]

I think you should use the Format Apple suggests (see https://developer.apple.com/library/ios/qa/qa1480/_index.html)

"yyyy'-'MM'-'dd'T'HH':'mm':'ss'Z'"

This because you are missing the T, and RFC3339 doesn't have a space between the fractional seconds and the timezone.

[rafcabezas]

I agree with @readefries on the default format. But like that you can change it using setDateFormat()

[evermeer]

I'm confused. There the Z is between quotes. So it will be written as just a Z and not as the zone info. I see this in the output "2016-01-28T06:32:34Z" Is that a format that only works when going from a String to a NSDate as the sample is doing?

So then for us it should be "yyyy'-'MM'-'dd'T'HH':'mm':'ssZ" which will result in dates like "2016-01-28T06:32:34+0000"

Besides that, I see you agree on a format without the milliseconds. I think that's indeed 99 out of 100 the preferred format, so lets stick to that. As you said, it's easy to set an other default if it's required.

[cloudcosmonaut]

Thats on purpose, as the timezone is set to UTC. And offset is only
important when displaying the date.
Op do 28 jan. 2016 om 07:51 schreef Edwin Vermeer notifications@github.com

I'm confused. There the Z is between quotes. So it will be written as just
a Z and not as the zone info. I see this in the output
"2016-01-28T06:32:34Z" Is that a format that only works when going from a
String to a NSDate as the sample is doing?

So then for us it should be "yyyy'-'MM'-'dd'T'HH':'mm':'ssZ" which will
result in dates like "2016-01-28T06:32:34+0000"

Besides that, I see you agree on a format without the milliseconds. I
think that's indeed 99 out of 100 the preferred format, so lets stick to
that. As you said, it's easy to set an other default if it's required.

—
Reply to this email directly or view it on GitHub
#35 (comment)
.

[rafcabezas]

"2016-01-28T06:32:34+0000" looks good to me. Thanks, @evermeer @readefries

[evermeer]

Then it's final.... for now....