Display of Date columns not working correctly

[ArneTR]

When I have a MySQL column of the DateTime type, phreeze identifies this correctly and I can also update it through the modal.

However, when I have the Date type column, Phreeze defaults to the current date and time, not showing the original value in the database.

The error lies on the Javascript site, as a call to /api/XXXX reveals, that the column is correctly read from the PHP site.

The problem is that app.parseDate delivers the wrong result.

Having a look at the template generated by phreeze:

<input type="text" class="date-picker input-xlarge" id="myID" value="<%= _date(app.parseDate(item.get('myID'))).format('YYYY-MM-DD') %>">

I modified it to :

<input type="text" class="date-picker input-xlarge" id="myID" value="<%= _date(app.parseDate(item.get('myID') + ' 00:00:00')).format('YYYY-MM-DD') %>">

Seems like app.parseDate requires a fully qualified language string, although if a detectable date has been submitted it should go with it and just omit the minutes.

[jasonhinkle]

Hmm interesting, thanks for finding that. I'll take a look and try to make parseDate a little more robust.

[jasonhinkle]

Hey Arne, would you mind posting a sample date value from your app that was causing problems? I can't reproduce it here, but it's possible there's a DB setting or something perhaps internationalization setting that outputs the dates slightly differently.

Also - is datepicker input control on the edit form showing the correct date? That would be interesting because the datepicker and the table both use the same date parsing function.

thanks again

[ArneTR]

Sry for the late reply.

What comes from the API, is what you expect from a MySQL Date column: "2012-08-04"

What gets retrieved by item.get() is also correct: "2012-08-04"

Then its get passed to app.parseDate(), which results in: Fri Sep 07 2012 21:48:21 GMT+0200 (CEST)

Then its gets consumed by _date, resulting in: 1347047395268

After calling .format('YYYY-MM-DD') it becomes: 2012-09-07 

So you can see, that the problem is with app.parseDate, which may be localized. I am using Chromium with an english locale in Germany. System time is GMT.

Problem persists between browsers. Not quite sure what causes this behaviour. Appending 00:00:00 however fixed it, as I said in the first post.

[jasonhinkle]

Hmm, thanks for the reply. I'll check that out. Since it returned sept 7 (which is today) then i'm guessing the parse function somehow failed and is returning the current time in order to return a valid date object instead of null or throwing an error.

i really want to reproduce this issue before I fix it so I don't wind up masking some other bug. but i'll try to do a little research into whether Javascript date parsing works differently depending on the browser setup. It looks like having the time in there forces it to parse correctly so that's an option but I just want to make sure I'm solving the root problem and not just a symptom.

[jasonhinkle]

OK found it & fixed in commit 449c1ee - there was a bug in app.js where when no time was provided it was throwing an exception instead of correctly appending the time. app.js is now marked as version 1.1, if you update that file then your project should work.

if you don't want to re-generate your app then you can just replace app.js with the one inside phreeze/builder/code/phreeze.backbone/scripts/app.js

[ArneTR]

Well still this behavior is weird. If I have a date in my database that is "NULL" this function displays the current date (Minutes, Hours and Seconds get set to 0).

But still, I would expect 0000-00-00 00:00:00 and not 2012-09-23 00:00:00

[jasonhinkle]

yea i'm not 100% sure what the best scenario for an illegal date in a date column would be. all zeros just gets converted to Nov 30, 1899 12:00 AM, and that's not equivalent to null. So it's probably not much better. If you wanted all zeros, though, that could be something done in the server side model code or something in "OnLoad"

I do agree that there should be some indication to the user that the date was adjusted. I don't like it when data is adjusted - even though it does write a warning to the console, the user probably won't notice that. Perhaps a validation warning could appear next to the date picker or something.

I'd say if you need to store null in date fields then it would probably require a UI that detects it and has some kind of date picker that supports null values (though i don't know of any personally).