Question

我有一个简单的XCTestCase：

func testExample() {
    let date = "2015-09-21T20:38:54.379912Z";// as NSString;
    let date1 = 1442867934.379912;

    XCTAssertEqual(date1, NSDate.sam_dateFromISO8601String(date).timeIntervalSince1970);
}

这个测试在不应该的时候通过，原因有两个：

1442867934.379912在测试中变为1442867934.379911，即使它只是一个变量重新打印
sam_函数（下面复制）似乎也以同样的方式思考，millisecond变量变为millisecond double 0.37991200000000003 0.37991200000000003，后来从NSDate转换为double ，似乎失去了微秒精度（调试器）： po NSDate.sam_dateFromISO8601String(date).timeIntervalSince1970 -> 1442867934.37991

po 1442867934.379912 -> 1442867934.37991

知道为什么吗？微秒精度（小数点后6位）对我的应用程序非常重要，我需要使用NSString格式与NSDate和iso8601无缝转换。

+ (NSDate *)sam_dateFromISO8601String:(NSString *)iso8601 {
    // Return nil if nil is given
    if (!iso8601 || [iso8601 isEqual:[NSNull null]]) {
        return nil;
    }

    // Parse number
    if ([iso8601 isKindOfClass:[NSNumber class]]) {
        return [NSDate dateWithTimeIntervalSince1970:[(NSNumber *)iso8601 doubleValue]];
    }

    // Parse string
    else if ([iso8601 isKindOfClass:[NSString class]]) {
        const char *str = [iso8601 cStringUsingEncoding:NSUTF8StringEncoding];
        size_t len = strlen(str);
        if (len == 0) {
            return nil;
        }

        struct tm tm;
        char newStr[25] = "";
        BOOL hasTimezone = NO;

        // 2014-03-30T09:13:00Z
        if (len == 20 && str[len - 1] == 'Z') {
            strncpy(newStr, str, len - 1);
        }

        // 2014-03-30T09:13:00-07:00
        else if (len == 25 && str[22] == ':') {
            strncpy(newStr, str, 19);
            hasTimezone = YES;
        }

        // 2014-03-30T09:13:00.000Z
        else if (len == 24 && str[len - 1] == 'Z') {
            strncpy(newStr, str, 19);
        }
        // 2014-03-30T09:13:00.000000Z
        else if (len == 27 && str[len - 1] == 'Z') {
            strncpy(newStr, str, 19);
        }


        // 2014-03-30T09:13:00.000-07:00
        else if (len == 29 && str[26] == ':') {
            strncpy(newStr, str, 19);
            hasTimezone = YES;
        }

        // Poorly formatted timezone
        else {
            strncpy(newStr, str, len > 24 ? 24 : len);
        }

        // Timezone
        size_t l = strlen(newStr);
        if (hasTimezone) {
            strncpy(newStr + l, str + len - 6, 3);
            strncpy(newStr + l + 3, str + len - 2, 2);
        } else {
            strncpy(newStr + l, "+0000", 5);
        }

        // Add null terminator
        newStr[sizeof(newStr) - 1] = 0;

        if (strptime(newStr, "%FT%T%z", &tm) == NULL) {
            return nil;
        }

        double millisecond = 0.0f;

        NSString *subStr = [[iso8601 componentsSeparatedByString:@"."].lastObject substringToIndex:6];

        millisecond = subStr.doubleValue/1000000.f;

        time_t t;
        t = mktime(&tm);

        return [NSDate dateWithTimeIntervalSince1970:t + millisecond];
    }

    NSAssert1(NO, @"Failed to parse date: %@", iso8601);
    return nil;
}

Answer 1

1442867934.379912和1442867934.379911可能非常相同，只是以不同方式打印相同的数字（一个圆形，另一个截断）...如果微秒时间对您很重要，也许您应该看一下{{ 3}}

特别是因为当时钟发生变化时，[NSDate日期]可能会发生变化......并且绝对时间api不会...

Answer 2

我最终只是更改了我的API以传递double对象的Time表示。即1442867934.379912根本没有弄乱ISO8601。

NSDate原生支持此功能。所以我不必解析任何字符串。因此，表现是一个额外的好处。

我在Rails / Rabl / Oj中遇到的几个怪癖：

需要将double作为string发送。似乎iOS上的JSONKit不会超过15位有效数字，JSON规范也不会。

Rabl（初始化者）：

Oj.default_options = {
  use_to_json: true,
  second_precision: 6,
  float_precision: 16
}

默认to_f未发送我需要的精度。

处理时间戳时失去双精度

2 个答案: