[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);
Comments
- zcopley 2011-04-15
Same thing happens when you call modificationTimestamp(), fyi. See: http://developer.appcelerator.com/helpdesk/view/38491">http://developer.appcelerator.com/helpdesk/view/38491
- zcopley 2011-04-15
Can we bump the priority on this? We'll have to fix this ourselves if it doesn't get fixed soon.
- ctredway 2011-04-15
Zach, tickets get initially assigned to Blain. It will prioritized by the team and then assigned.
- zcopley 2011-04-15
Okay, noted. Thank you.
- Sid Ahuja 2011-04-15
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!
- Stephen Tramer 2011-04-15
KS tests make it look like this is fixed. Thom, confirm?
- Thomas Huelbert 2011-04-15
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)