Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-1644] file.createTimeStamp returns either 0 or 1

GitHub Issuen/a
TypeBug
PriorityMedium
StatusClosed
ResolutionFixed
Resolution Date2011-04-17T01:56:45.000+0000
Affected Version/sn/a
Fix Version/sRelease 1.5.0
ComponentsiOS
Labelsdefect, file, ios, iphone, timestamp
Reporterctredway
AssigneeBlain Hamon
Created2011-04-15T02:58:12.000+0000
Updated2011-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

  1. 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

  2. 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.

  3. ctredway 2011-04-15

    Zach, tickets get initially assigned to Blain. It will prioritized by the team and then assigned.

  4. zcopley 2011-04-15

    Okay, noted. Thank you.

  5. 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!

  6. Stephen Tramer 2011-04-15

    KS tests make it look like this is fixed. Thom, confirm?

  7. 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)

JSON Source