2013-07-12 1 views
3

Как говорится в названии после того, как я назначил объект DateTime с часовым поясом UTC, он теряет свою информацию TimeZone при назначении DataRow.CZ TimeZone информация потеряна при назначении DateTime DataRow

static void Main(string[] args) 
    { 
    DateTime universalTime = DateTime.UtcNow; 

    DataTable table = new DataTable(); 
    table.Columns.Add("Time", typeof(DateTime)); 
    DataRow row = table.NewRow(); 

    row["Time"] = universalTime; 

    /* writes Kind: Utc */ 
    Console.WriteLine("Universal time  : " + universalTime + ", kind: " + universalTime.Kind); 

    /* writes Kind: Unspecified */ 
    Console.WriteLine("Same time in DataRow: " + row["Time"] + ", kind: " + ((DateTime)row["Time"]).Kind); 

    Console.ReadKey(); 
    } 

После присвоения DataRow он говорит Kind = Unspecified.

Является ли это ошибкой в ​​DataRow или я делаю что-то не так?

+4

Кажется, его уже ответил [http://stackoverflow.com/questions/3990809/how-to-persist-datetime-kind-while-storing-a-datetime-object -into-a-data-table] – Rwiti

+0

Это имеет значение? Для хранения времени в базах данных сохранение в формате UTC является единственным форматом, который имеет смысл в любом случае. – spender

+0

У дуп-сообщения есть ответ, но также следует помнить, что 'Kind' на самом деле не хранит информацию о часовом поясе. Это просто правило, в котором говорится, как нужно обрабатывать значение при взаимодействии с функциями часового пояса. И, как правило, он не сохраняется при сохранении данных. Вы можете думать о «UTC» как часовом поясе, но типы «Local» или «Unspecified» немного отличаются. Если настойчивость - это то, что вам нужно, вы можете посмотреть «DateTimeOffset». Даже если ваше смещение равно нулю, оно, по крайней мере, будет сохраняться таким образом и не будет потеряно. –

ответ

0

Я подозреваю, что это связано с отсутствием информации о часовом поясе в вашем типе данных datetime вашего уровня.

Например, на SQL Server тип datetime не имеет информации о часовом поясе. Таким образом, любое значение C# типа DateTime имеет только сохраненное значение. Это похоже на то, как работают Linq-to-SQL и Entity Framework.

Как правило, мой рабочий процесс заключался в определении часового пояса (UTC) для всех сохраненных значений DateTime и выполнения преобразований перед сохранением и после извлечения.

Что-то вроде этого:

public DateTime InputTime(DateTime time) { 
    if (time.Kind == DateTimeKind.Unspecified) { 
     throw new ArgumentException("Time values cannot be input to the data store with unspecified kind."); 
    } 
    return time.ToUniversalTime(); 
} 

public DateTime OutputTime(DateTime time) { 
    if (time.Kind == DateTimeKind.Unspecified) { 
     time = DateTime.SpecifyKind(time, DateTimeKind.Utc); 
    } 
    return time.ToUniversalTime(); 
} 
+0

Интересно, но я не уверен, что это имеет смысл. Для 'InputTime' обычно даты, начинающиеся с ввода, являются' Unspecified', потому что они анализируются из строк в пользовательском интерфейсе. Для 'OutputTime', это, конечно, не имеет смысла, потому что вы отмечаете время как UTC, но затем пытаетесь преобразовать его в UTC снова, что было бы не-op. Я не уверен, как любой из них поможет решению проблемы OP. Но спасибо за попытку. –

+0

@MattJohnson - Даты от пользовательского интерфейса должны быть преобразованы в 'DateTimeKind.Local' далеко впереди слоя сохранения. Вот почему «InputTime» выдает исключение: даты должны иметь известный «Добрый» перед сохранением. Метод «OutputTime» предназначен для приема дат непосредственно из уровня персистентности, которые почти во всех случаях (но, возможно, не в сценариях с единичным тестированием) не заданы «Kind». он применяет тип UTC и возвращает это значение в UTC (который также является возвращаемым видом, если параметр 'time' имеет указанный« вид ». – ken

+0

Не пытайтесь начать аргумент, но я должен не согласиться с вами. почти все случаи, 'DateTimeKind.Local' злой. Прочитайте [мой пост в блоге по теме] (http://codeofmatt.com/2013/04/25/the-case-against-datetime-now/), и если вы мне не верите - см. [то, о чем подумал Джон Скит] (http://noda-time.blogspot.com/2011/08/what-wrong-with-datetime-anyway.html). удобство в * чистом рабочем столе * приложениях, но кроме этого он просто мешает и делает беспорядок. –

 Смежные вопросы

  • Нет связанных вопросов^_^