[TIMOB-1644] file.createTimeStamp returns either 0 or 1
| GitHub Issue | n/a |
|---|---|
| Type | Bug |
| Priority | Medium |
| Status | Closed |
| Resolution | Fixed |
| Resolution Date | 2011-04-17T01:56:45.000+0000 |
| Affected Version/s | n/a |
| Fix Version/s | Release 1.5.0 |
| Components | iOS |
| Labels | defect, file, ios, iphone, timestamp |
| Reporter | ctredway |
| Assignee | Blain Hamon |
| Created | 2011-04-15T02:58:12.000+0000 |
| Updated | 2011-04-17T01:56:45.000+0000 |
Description
In iOS 4 and 4.0.2 using sdk 1.4 the following code to create a timestamp of a file returns a 1 and not the date
var filename = 'iphone_coming_soon.png'; var timeStampOfFile = ''; var file = Titanium.Filesystem.getFile(Titanium.Filesystem.applicationDataDirectory,filename); if ( file.exists() ) { Ti.API.info('IF IS TRUE'); timeStampOfFile = file.createTimestamp(); }
Ti.API.info('The value of timeStampOfFile is: ' + timeStampOfFile);
Same thing happens when you call modificationTimestamp(), fyi. See: http://developer.appcelerator.com/helpdesk/view/38491">http://developer.appcelerator.com/helpdesk/view/38491
Can we bump the priority on this? We'll have to fix this ourselves if it doesn't get fixed soon.
Zach, tickets get initially assigned to Blain. It will prioritized by the team and then assigned.
Okay, noted. Thank you.
createTimestamp() and modificationTimestamp() both return 0. This also happens in the kitchensink app so it's definitely a bug. I have tried this on both iPhone and iPad SDKs 3.2 and 4.0.
This is messing with the caching logic so please fix soon - thanks!
KS tests make it look like this is fixed. Thom, confirm?
mobile sdk build 1.5.0.d5d8dbe - 4.0.1 and 4.1 look good, are fixed. I am getting an unexpected value for created on 3.1.2/3.2.2 (iphone/ipod or ipad) though:
[INFO] newfile.txt created: Wed Dec 31 1969 16:00:00 GMT-0800 (PST)
modified looks good:
[INFO] newfile.txt modified: Wed Oct 13 2010 13:32:59 GMT-0700 (PDT)
I'm opening a new bug for < 3.2.2 (incorrect time value) and closing this record (no longer returning 0 or 1)