Swift - Weird Time Formatter [дубликат]

Ваш запрос Строка неверна

String selectQuery = "SELECT "+colID+ " FROM " + allScreens + " WHERE " + colName + " = '" +name + "'";

имя, которое вы указываете, где должно быть в одинарных кавычках

0
задан Duncan C 8 October 2016 в 21:48
поделиться

1 ответ

NSDate (или Date in Swift 3) не имеет часового пояса. Он записывает мгновение во времени по всему миру.

Внутренне, объекты даты записывают количество секунд со времени «даты эпохи» или «Полночь» 1 января 2001 года в по времени по Гринвичу , aka UTC.

Обычно мы думаем о датах в нашем локальном часовом поясе.

Если вы регистрируете дату, используя

print(NSDate()) 

Отображается система текущую дату, но она выражает это в UTC / Greenwich Mean Time. Таким образом, единственное место, где время будет выглядеть правильно, - это тот часовой пояс.

Вы получаете ту же проблему в отладчике, если вы выдаете команду отладчика

e NSDate()

Это боль , Я лично хотел бы, чтобы iOS / Mac OS отображали даты с использованием текущего часового пояса пользователя, но они этого не делают.

EDIT # 2:

Улучшение моего предыдущего использования локализованной строки что делает его немного проще в использовании - создать расширение для класса Date:

extension Date {
    func localString(dateStyle: DateFormatter.Style = .medium, timeStyle: DateFormatter.Style = .medium) -> String {
        return DateFormatter.localizedString(from: self, dateStyle: dateStyle, timeStyle: timeStyle)
    }
}

Таким образом, вы можете просто использовать выражение типа Date().localString() или хотите только распечатать время, вы можете использовать Date().localString(dateStyle:.none)

EDIT:

Я только что обнаружил, что NSDateFormatter (DateFormatter в Swift 3) имеет метод класса localizedString. Это делает то, что делает мое расширение ниже, но более просто и чисто. Вот объявление:

class func localizedString(from date: Date, dateStyle dstyle: DateFormatter.Style, timeStyle tstyle: DateFormatter.Style) -> String

Итак, вы просто используете

let now = Date()
print (DateFormatter.localizedString(
  from: now, 
  dateStyle: .short, 
  timeStyle: .short))

. Вы можете в значительной степени игнорировать все ниже.


I создали категорию класса NSDate (Date in swift 3), которая имеет метод localDateString, который отображает дату в локальном часовом поясе пользователя.

Вот категория в форме Swift 3: (filename Date_displayString. swift)

extension Date {
  @nonobjc static var localFormatter: DateFormatter = {
    let dateStringFormatter = DateFormatter()
    dateStringFormatter.dateStyle = .medium
    dateStringFormatter.timeStyle = .medium
    return dateStringFormatter
  }()

  func localDateString() -> String
  {
    return Date.localFormatter.string(from: self)
  }
}

И в форме Swift 2:

extension NSDate {
   @nonobjc static var localFormatter: NSDateFormatter = {
    let dateStringFormatter = NSDateFormatter()
    dateStringFormatter.dateStyle = .MediumStyle
    dateStringFormatter.timeStyle = .MediumStyle
    return dateStringFormatter
  }()

public func localDateString() -> String
  {
    return NSDate.localFormatter.stringFromDate(self)
  }
}

(Если вы предпочитаете другой формат даты, довольно легко изменить формат, используемый форматом даты.

Я бы предложил разместить соответствующую версию этого файла Swift 2 / Swift 3 во всех ваших проектах.

Затем вы можете использовать

Swift 2:

print(NSDate().localDateString())

Swift 3:

print(Date().localDateString())
9
ответ дан Duncan C 16 August 2018 в 00:40
поделиться
  • 1
    Если вы пытаетесь представить канонический ответ, в котором используется переменная static, то я думаю, что вам лучше ответить на NSLocale.currentLocaleDidChangeNotification (a.k.a. NSCurrentLocaleDidChangeNotification) и недействить / сбросить кешированные форматирующие элементы. Если вы не хотите спускаться с этой кроличьей дыры, то, возможно, extension с static не входит в состав этого «канонического» слова. ответьте, и просто оставьте его при использовании "DateFormatter, как это ...". – Rob 8 October 2016 в 22:48
  • 2
    Роб, точка взята. Я предполагаю, что «канонический ответ» было немного, учитывая, что пользователь может изменить локали, как вы указываете. Больше похоже на портативное, простое решение общей проблемы разработки / отладки. Поскольку это в первую очередь для поддержки развития, переключение локалей на самом деле не похоже на проблему. – Duncan C 9 October 2016 в 02:55
Другие вопросы по тегам:

Похожие вопросы: