PDA

View Full Version : datepicker and return format



sharky
24 Feb 2011, 6:38 AM
Hi,

I have a difference in values following the recovery method.
if I insert 01-01-2010 in the datepicker :

Return by getValues (date object)
Fri Jan 01 2010 00:00:00 GMT+0100 (Paris,Madrid)

Return by submit form (var post in my php script)
2009-12-31T23:00:00.000Z

what is the problem ?

(Sry for my dirty English :s)

psenough
14 Apr 2011, 11:20 PM
i have same problem that is not allowing me to save / reload from localstorage
saves output of picked as "1981-01-01T22:00:00.000Z"
and doesnt accept that format when loading..
:-?

also tried using



Ext.apply(Ext.util.Format, {
defaultDateFormat: 'd-m-Y'
});



seems to ignore it

sharky
14 Apr 2011, 11:27 PM
a solution here :

http://www.developpez.net/forums/d1042996/webmasters-developpement-web/javascript/bibliotheques-frameworks/ext-js-sencha/datepicker-format/

psenough
14 Apr 2011, 11:35 PM
a solution here :

http://www.developpez.net/forums/d1042996/webmasters-developpement-web/javascript/bibliotheques-frameworks/ext-js-sencha/datepicker-format/

thats more of an explanation on the existance of the different date formats than an actual solution.

psenough
14 Apr 2011, 11:58 PM
tried parsing it with one of the patterns listed here
http://dev.sencha.com/deploy/touch/docs/?class=Date
but seems none match the extra .000Z
have no idea what they are or why are they getting added, but i reckon its a bug O_o
have to check the sourcecode to fix it if no devs show up :/

sharky
15 Apr 2011, 12:16 AM
Z = Timezone offset in seconds (negative if west of UTC, positive if east) -43200 to 50400

Documents you about dates in ISO-8601 : http://en.wikipedia.org/wiki/ISO_8601

Time zone designators

There are no time zone designators in ISO 8601. Time is only represented as local time or in relation to UTC.

if no UTC relation information is given with a time representation, the time is assumed to be in local time. While it may be safe to assume local time when communicating in the same time zone, it is ambiguous when used in communicating across different time zones. It is usually preferable to indicate a time zone (zone designator) using the standardís notation.

If the time is in UTC (http://en.wikipedia.org/wiki/Coordinated_Universal_Time), add a 'Z' directly after the time without a space. 'Z' is the zone designator for the zero UTC offset. "09:30 UTC" is therefore represented as "09:30Z" or "0930Z". "14:45:15 UTC" would be "14:45:15Z" or "144515Z".
UTC (http://en.wikipedia.org/wiki/Coordinated_Universal_Time) time is also known as 'Zulu' time, since 'Zulu' is the NATO phonetic alphabet (http://en.wikipedia.org/wiki/ICAO_spelling_alphabet) word for 'Z'.

psenough
15 Apr 2011, 12:21 AM
makes sense. so the saving is being done ok.

its just the loading from localstorage store model into a datepickerfield that doesnt seem to be working. /:) text loads fine into textfield. have to debug.

psenough
15 Apr 2011, 1:11 AM
found a solution on another thread
model field required a mandatory use of dateFormat:'c'

{name: 'ourDate', type:'date', dateFormat:'c'},

very badly documented if you ask me 8-|

Dig4Fire
15 Apr 2011, 1:12 PM
found a solution on another thread
model field required a mandatory use of dateFormat:'c'

{name: 'ourDate', type:'date', dateFormat:'c'},

very badly documented if you ask me 8-|

Doesn't work for me

katamshut
13 Sep 2011, 3:50 PM
I had the same problem. I solved it by a workaround. My application is working within the same timezone so I send my proxy request with extra params:


this.store.proxy.extraParams = {
fromDate: fromDate.format('Y-m-d G:i'),
toDate: toDate.format('Y-m-d G:i'),
action: 'insert'
};

so I can be sure that I handle with a string which gets not converted by the proxy.

After inserting the data I just reload my list from the server instead of using the store which is actually just substracts or add add the timezone to the date fields.

maybe there is a better way...