mobilepickDate return value problem

[slowdash]

according to the dictionary the mobilePickDate returns
-The selected date, time or date and time are returned in the result. The value is in seconds since the UNIX Epoch.

somehow on my tests, the result returns a "wrong" formatted date

ex: january 1, 2012 becomes 11/30/2012
ex: december 1, 2012 returns 11/1/2012

i have a button and below is the code im using

Code: Select all

on mouseUp
    mobilePickDate "date"
    answer the result   
end mouseUp

[Klaus]

Hi slowdash,

what exactly is in your "the result" and how do you convert it back to a readable date?


Best

Klaus

[slowdash]

hi klaus,

that's the whole code there, i am not converting it in any way, it doesnt return seconds, instead it returns a wrong formatted date

[Dixie]

Slowdash...

It doesn't return the result in seconds but in date format...
From the release notes...

When the date picker is dismissed by the user, the selected date will be stored in the result

To get the seconds value of the date , just convert it...

Code: Select all

on mouseUp
   mobilePickDate "date"
   put the result into theChosenDate
   convert theChosenDate to seconds
   put theChosenDate into fld 1
end mouseUp

be well,

Dixie

[dave_probertGA6e24]

Hi Slowdash,

I just cut and pasted your code into a button and made an app of it. Testing on my iPad with the two dates you show gave the correct results - Jan 1st 2012 = 1/1/12 and Dec 1st 2012 = 12/1/12

Not a clue what all this fuss is regarding seconds, etc. the result simply contains a string of the date "mm/dd/yy" (or whatever format is configured on the device) as far as I can see.

Were you testing in the Simulator?

Cheers,
Dave

[slowdash]

hi dixie and dave, first thanks for replying

dixie, i actually dont mind if it returns seconds or a formatted date, i can easily format it either way, what im concerned about is that it returns
a wrong value

dave, i probably forgot, but im developing for android, i tested using a pantech tablet (3.2 android version) and an emulator.

im still having problems with regards to the value it returns

ex: january 1, 2012 becomes 11/30/2012
ex: december 1, 2012 returns 11/1/2012

ex: august 31 2012 returns 07/30/12

[Dixie]

Slowdash...

That seems to be a strange one as it returns correctly for me..!

be well,

Dixie

[JacobS]

Hi all,

I am also having the same problem as Slowdash. Did you ever find a solution for Android? Right now I have a function that converts the wrong date to the correct one, but I'd like to not use that if possible!

Thanks,
Jacob

[sturgis]

Similar problem here, kindle fire. Jan 1, 12 for me returns 12/31/11. Not as wiggy a result as yours. In my case i'm sure its the whole daylight savings time thing. Looks like the seconds is returned and lc "handles" it for me but doesn't make allowances for the hour diff, so its off a day, and will be off a day for any date checked until the next savings time switch. Pain in the tookus it is. Think it might be easiest to roll your own date control that actually works. Still not sure why your results are so much farther off. Either way, the daylight savings error should be reported as a bug?

[dcpbarrington]

I'm having the same problem with the mobilePickDate on LiveCode V5.5.5 on Android V2.2.

I have two button with a simple mobilePickDate call
mobilePickDate "Date"
and
mobilePickDate "Time"

The result are NOT returned in Seconds as the documentation describes, but in the short Date and Time format. In addition both the Date and Time are not returned correctly.

Select date 4/5/2013 and you get 4/4/2013 One day less than selected
Select time 11:15 AM you get 5:15 AM Six hours less than selected. My current time zone is GMT-5:00

I've had to adjust the returned time for it to be accurate.
Is this a bug that everyone is dealing with?
Do a Bug need to be created?

[rinzwind]

Documentation still is plain wrong. Nothing is returned in seconds. It is formatted in short date (I think)... not so handy and also makes handling dates in a distant past impossible.

I wonder how the excample in the docs could ever have worked... was it different in old iOS versions? Event the value returned when the user cancels the datepicker is not 0, but "cancel". Luckily independent of iPhone iOS language...