2015-11-01 2 views
5

Я новичок в NodaTime, и я хотел бы реализовать его в своем приложении.Как обработать строку даты объекту NodaTime?

Как я могу проанализировать строку даты для объекта NodaTime?

Вот что я в настоящее время:

var dateInput = "06/11/2015"; 
var pattern = InstantPattern.CreateWithInvariantCulture("dd/MM/yyyy"); 
var parseResult = pattern.Parse(dateInput); 
var localDate = parseResult.Value; 
DateTimeZone tzNZ = DateTimeZoneProviders.Tzdb["Asia/Hong_Kong"]; 
ZonedDateTime result = localDate.InZone(tzNZ); 

моя переменная LocalDate теперь 2015-11-06T00:00:00Z (и на основании того, что я прочитал в формате ISO, имеющие Z в последней части указано, что это UTC)

мой результат переменная в настоящее время 2015-11-06T13:00:00 NZ (+13)

Но я не уверен, что я на правильном пути.

Вот что я действительно хочу.

  1. Преобразование (строку даты) dateInput к объекту NodaTime в следующем формате dd/MM/yyyy
  2. А затем как UTC затем преобразовать в тип long данных затем сохранить его в базу данных
  3. Затем попытайтесь извлекать сохраненные данные, а затем использовать определенный часовой пояс. Say Asia/Hong_Kong

Возможно ли это?

EDIT

var dateInput = "06/11/2015"; 
var pattern = LocalDatePattern.CreateWithInvariantCulture("dd/MM/yyyy"); 
LocalDate parseResult = pattern.Parse(dateInput).Value; 
DateTimeZone tzHK = DateTimeZoneProviders.Tzdb["Asia/Hong_Kong"]; 
LocalTime time = GetTimeOfDay(); 
LocalDateTime localDateTime = parseResult + time; 

// change it to UTC then convert it to 
// long data type then save it to the database 

// methods 
private LocalTime GetTimeOfDay() 
{ 
    var instant = SystemClock.Instance.Now; 
    var tz = DateTimeZoneProviders.Tzdb["Asia/Hong_Kong"]; 

    return instant.InZone(tz).TimeOfDay; 
} 

У меня есть этот фрагмент кода, и этот сценарий, в котором пользователь может ввести только date сказать 06/11/2015 то при сохранении его в базу данных, мне нужно это текущее время (текущее время пользователя) для просмотра. Причина, по которой я конвертирую его в long, заключается в том, что я использую Entity Framework.

Возможно ли это?

+0

Вопрос о вашем редактировании - Почему у вас есть они вообще введите дату в этом сценарии? Похоже, что вы указываете дату с указанием даты и времени. –

+0

@MattJohnson Это просто идея, которую я придумал. и я просто понимаю, что это не имеет никакого смысла. Я думаю, мне нужно удалить его. –

+0

Да, если бы вы были просто timestamping, то ничего из этого не касается, поскольку вы просто используете 'SystemClock.Instance.Now', чтобы получить текущий« Мгновенный »UTC. Или просто используйте 'DateTime.UtcNow' или подобную функцию в вашем db, а затем вам не понадобится Noda Time. –

ответ

5

Я отвечу с несколько иной точки зрения. Вы сказали, что конвертируете в long, потому что вы используете Entity Framework. Это, вероятно, не нужно.

Похоже, вы просто пытаетесь округлить календарную дату. Если нет конкретного времени (например, полночь или начало дня), и вы хотите, чтобы все пользователи видели один и тот же год месяц и день независимо от того, в каком часовом поясе они находятся, тогда было бы лучше (IMHO) сохраняйте вещи в этих условиях на протяжении всего процесса.

Некоторые утверждают, против этого, с общей лучшей практикой, чтобы быть «всегда хранить в UTC», но этот совет не имеет место в двух общих сценариях:

  1. «У меня есть местный дата и время, но они в будущем, и я использую их для планирования ».

  2. «Я просто работаю с календарной датой без какого-либо времени суток, это может быть прошлым или будущим, но это гражданская дата, ориентированная на человека, а не уникальный момент времени."

Вы, кажется, во втором случае так:.

  • Использовать дату только типа в базе данных, таких как тип DATE доступных в SQL Server, PostgreSQL, MySQL, Oracle, и большинство других реляционных баз данных.

  • Используйте LocalDate типа в Нода времени. не пытайтесь превратить его в Instant, LocalDateTime, ZonedDateTime, или long.

  • Использовать тип DateTime.Kind == DateTimeKind.Unspecified), чтобы действовать как посредник между базой данных и вашим имуществом LocalDate. Это обычно делается с шаблоном «свойства приятеля», как видно in this answer.

+0

Заметьте, я делаю несколько предположений в своем ответе. Если вы на самом деле не просто пытаетесь округлить дату календаря, тогда дайте мне знать, и я удалю или пересмотрю свой ответ. Благодарю. –

+0

О, так что я мог бы использовать что-то вроде вашего подхода, чтобы использовать 'DATE' и хранить' DATE' только в базе данных и не беспокоиться о правиле «всегда хранить в UTC»? Я всегда думал и основывался на том, что я читал, что вы всегда должны хранить в UTC. Я никогда не думал, что есть исключение. Я не совсем уверен, что такое «поездка туда и обратно». –

+0

Да, вот что я имею в виду. «round-trip» - это идея, что вы получаете точное значение, которое вы сохранили или передали. Он начинается с строки «2015-11-01», «сохраняется в базе данных как« 2015-11-01 »и может быть загружен из базы данных с тем же значением. (Кое-что, что не крутится в оба конца, будет похоже на установку 'DateTimeKind.Utc', которая не сохраняется в базе данных, так что при возврате будет' DateTimeKind.Unspecified'.) –