Почему LocalDateTime не является локальным датой и временем?

Question

Как архитектор программного обеспечения, я бы очень хотел использовать NodaTime, но концепция «Локальный» делает наш код чрезвычайно трудным для работы (и это заставляет меня и мои команды гайки)! documentation, когда речь идет о «местный» и «глобальный» раз заявляет следующее:

Основное различие заключается в том, что люди во всем мире согласятся на глобального значения а одновременно, в то время как все они могут видеть разные местные значения для того же глобального значения, из-за часовых поясов.

Это предложение определяет, что такое глобальное время, используя определение Локального времени. Поэтому, прежде чем мы сможем понять глобальное время, мы должны сначала понять, что такое Местное время.

Google (и многие другие словари аналогично) определяет "Local Time", как:

времени, как считаться в конкретном регионе или часового пояса.

• время в определенном месте, измеренное от прохождения солнца над меридианом в этом месте, определенное как полдень.

Так, местное время в определенное время, которое определяется (или связан с) часового пояса в - получил. Теперь мы полностью понимаем, что означает глобальное время; не в порядке, следующее предложение:

Локальное значение имеет не связано часового пояса в Noda времени;

Подождите! Что за...?! Документация, только что сделанная, определяющая глобальное время, используя общепринятое определение локального времени (которое - это, связанное с часовым поясом), и теперь они решают полностью отрицать его смысл, если это правда, что означает глобальное время? ИМХО, абсолютно ничего.

документация переходит к государству ...

, в частности, это не просто «дата и время прикреплено к местному времени компьютера работает код»

у меня есть две проблемы с этим утверждением:

1. документация не может с помощью универсальное определение «местное время» до попробуйте, чтобы описать, что это такое. Это как сказать: X is equal to (NOT X) is true.
2. Поскольку использование даты и времени компьютера составляет точно определение «Местное время», то что я могу назвать местным временем?

Я голосую за то, что мы используем лучшее определение, чем «Местное», как насчет слова «Сырье»? Что означает:

Быть в естественном состоянии или почти в естественном состоянии: не обрабатывается и не очищается.

Хммм ....

А [сырые] значение имеет нет ассоциированных часового пояса в Noda времени; , в частности, это не просто «дата и время прикреплено к местному времени компьютера работает код»

Теперь, больше походит на определение документации пытается передать.

Возможно, кто-то может придумать лучшее слово, чем «Сырье»; но дело в том, пожалуйста, верните реальный смысл «Местный», поскольку «Локальный» имеет очень реальное и очень полезное значение в программном обеспечении и в жизни.

Таким образом, мы можем переименовать Local[Date][Time] классы Raw[Date][Time] и (необязательно) добавлять новые классы, называемые Local[Date][Time], что является привязан к локальной временной зоне компьютера?

---

@Michal & @J ... -

Проблема, которую мы имеем, не понимая LocalDateTime в 'наш' местный (потому что это неподпоясанный). Проблема, которую мы имеем с LocalDateTime, заключается в том, что она is без зонирования. По существу, LocalDateTimeдолжен быть, по определению, особым типом ZonedDateTime. (Так же, как и UTC, концептуально (и конкретно) особый тип ZonedDateTime. Таким образом, UTC может иметь собственный набор типов, например: Utc[Date][Time], что, учитывая правильную проблемную область, может быть очень полезным. И поскольку UtcDateTime не имеет «мы взяли», мы могли бы создать такую ​​концепцию, не вмешиваясь в NodaTime.)

Назад к нашей проблеме, например: если у меня есть два ZonedDateTimes, один из Нью-Йорка и другой из Сиэтла, и я хочу изучить эти два ZonedDateTimes из моего текущего местоположения (скажем: Даллас). Я хотел бы написать ...

LocalDateTime fromNy = newYork.LocalDateTime; 
LocalDateTime fromWa = seattle.LocalDateTime; 

Но вместо этого, я получаю два несвязанных местного времени даты, которые не имеют абсолютно никаких отношений друг с другом. На самом деле, если бы не имена var, я бы не знал, что есть.

Что я хочу, это два ZonedDateTimes, которые были преобразованы в мой местный часовой пояс, как предлагает название свойства. Теперь эти два значения LocalDateTime (где LocalDateTime - особый тип ZonedDateTime) имеют соответствующее значение.Я знаю, что могу получить то, что близко к тому, что я хочу, делая следующее: но он грязный, не передает одну и ту же семантику и теряет информацию о часовом поясе.

DateTimeZone ct = BclDateTimeZone.ForSystemDefault(); 
LocalDateTime tx1 = newYork.WithZone(ct); 
LocalDateTime tx2 = seattle.WithZone(ct); 

Я хотел бы также, чтобы иметь возможность преобразовать значения снова как так:

ZonedDateTime wa = tx2.WithZone(seattleTimeZone); 
ZonedDateTime nw = tx2.WithZone(nyTimeZone); 

Что также позволит:

instant.InUtc(); 
instant.InZone(zone); 
instant.InLocal(); 

Таким образом, имея возможность отображения мгновенного к 3 наиболее частым часовым поясам; UTC, местные и другие. Но я не могу, поскольку LocalDateTime не является особым типом ZonedDateTime.

IMHO, NodaTime 1.x хорошо, но он не является гибким (или жидким), достаточным для использования в прайм-тайм. Но хорошая новость заключается в том, что это далеко не так. Надеемся, что в 2.0 (или раньше) эти проблемы могут быть решены.

@Michal - Мне нравится ваша идея Noda[Date][Time] в отличие от Raw[Date][Time].

Answer 1

То, что вы, вероятно, путаясь с это:

LocalDateTime = родовое время в определенном календаре (например, григорианский), но поскольку нет TimeZone прилагается к нему, вы не можете различить, какой точный момент на Global это произошло. Представьте, что это всего лишь общая ценность. Например. 14:00. Вы не будете знать, когда именно 14:00 происходит потому, что ваш не хватает, что TimeZone это в.

ZonedDateTime = в конкретной временной зоне LocalDateTime (то, что вы, вероятно, воображая, как LocalDateTime).

Я, вероятно, согласен с вами в том, что это немного неверно. И я бы предпочел, чтобы он назывался NodaDateTime и ZonedDateTime, который будет называться LocalDateTime, поскольку он выглядит более логичным.

EDIT - следующий комментарий

Лично я редко используют LocalDateTime, если вы будете придерживаться между Instant и ZonedDateTime вы, вероятно, избавиться от многих ваших головных болей. Существует очень хороший обзор схема преобразования между типами:

Взятые От: nodatime.org - User Guide - Converting Between Types

Так что в вашем случае, что вы хотите делать, является преобразование конкретного ZoneDateTime в Instant, а затем обратно к вашему желанию ZonedDateTime (ваша система tz)

Например

var myTz = BclDateTimeZone.ForSystemDefault(); 

var fromNy = SystemClock.Instance.Now.InZone(DateTimeZoneProviders.Tzdb["America/New_York"]); 
// fromNy = 2015-03-22T08:28:56 America/New_York (-04) 

var fromLa = SystemClock.Instance.Now.InZone(DateTimeZoneProviders.Tzdb["America/Los_Angeles"]); 
// fromLa = 2015-03-22T05:28:56 America/Los_Angeles (-07) 

var fromNyInMyTz = fromNy.ToInstant().InZone(myTz); 
// localFromNy = 2015-03-22T12:28:56 GMT Standard Time (+00) 

var fromLaInMyTz = fromLa.ToInstant().InZone(myTz); 
// localFromLa = 2015-03-22T12:28:56 GMT Standard Time (+00) 

Вы также можете создать метод расширения:

public static class NodaExtensions 
{ 
    public static ZonedDateTime InUtc(this ZonedDateTime dt) 
    { 
     return dt.ToInstant().InUtc(); 
    } 
    public static ZonedDateTime InZone(this ZonedDateTime dt, DateTimeZone tz) 
    { 
     return dt.ToInstant().InZone(tz); 
    } 
    public static ZonedDateTime InLocal(this ZonedDateTime dt) 
    { 
     return dt.ToInstant().InZone(BclDateTimeZone.ForSystemDefault()); 
    } 
} 

что позволяет:

var fromNyInUtc = fromNy.InUtc(); 
var fromLaInUtc = fromLa.InUtc(); 

var fromNyInZone = fromNy.InZone(myTz); 
var fromLaInZone = fromLa.InZone(myTz); 

var fromNyInLocal = fromNy.InLocal(); 
var fromLaInLocal = fromLa.InLocal(); 

Это то, что вы предпочли бы?