Парсинг даты без учёта часового пояса

            string s = "2023-10-23T11:48:08.879Z"; //Это, я так понимаю, GMT?
            string format = "yyyy-MM-ddTHH:mm:ss.fffZ";
            if (DateTime.TryParseExact(s, format,
                null, DateTimeStyles.None,
                out DateTime dateTime))
            {
                System.Diagnostics.Debug.WriteLine(dateTime);
            }

Возвращает 23.10.2023 18:48:08.
Какие параметры передать, чтобы он часовой пояс не учитывал? Я их штук 5 перепробовал, но результат вообще не меняется.

ChatGPT говорит: «вы можете использовать DateTimeStyles.AssumeUniversal для указания, что строка даты и времени должна быть интерпретирована как UTC.»

«AssumeUniversal 64
Если в анализируемой строке часовой пояс не указан, подразумевается, что используется время в формате UTC.»

«Буква Z в строке 2023-10-23T11:48:08.879Z означает, что время представлено в формате UTC (Coordinated Universal Time), также известном как GMT (Greenwich Mean Time).
В контексте формата ISO 8601, который используется в данной строке, Z обозначает “Zulu time”, что является эквивалентом UTC. Это обозначение было принято из авиационной терминологии, где “Zulu” - это код, используемый для обозначения времени по Гринвичу»

«Перед выводом в строке “System.Diagnostics.Debug.WriteLine” если DateTime.Kind не равно DateTimeKind.Utc, вам может потребоваться преобразовать значение в UTC с помощью метода DateTime.ToUniversalTime()»

1 лайк

Но это и было первое, что я попробовал :man_shrugging:
У меня есть вот такой старый код:

        public static DateTime TwitchTimeToDateTime(string t, bool localTime)
        {
            return DateTime.ParseExact(t, "MM/dd/yyyy HH:mm:ss",
                CultureInfo.InvariantCulture,
                localTime ? DateTimeStyles.AssumeUniversal : DateTimeStyles.AssumeLocal);
        }

И это, вопреки здравому смыслу, работает! Может, потому что входная строка немного другая :thinking:
А в примере из первого поста, какие параметры ни задавай - выхлоп не меняется :man_shrugging:

У Вас же во входной строке указано, что в время в формате UTC (см. пост @Двойкин выше)
Если его вывести в формате универсального времени, то оно и будет такое, какое Вы задали.
А если выводить локальное, то оно у Вас будет отличаться от универсального времени, потому что в локальном времени присутствует и смещение по часовому поясу.

проиллюструю ответ кодом примером:

			string s = "2023-10-23T11:48:08.879Z"; 
            string format = "yyyy-MM-ddTHH:mm:ss.fffZ";
            DateTime localDateTime;
            if (DateTime.TryParseExact(s, format,
                                       null, System.Globalization.DateTimeStyles.None, out localDateTime))
            {
           		DateTime univDateTime = localDateTime.ToUniversalTime();
            	Console.WriteLine("{0} local time is {1} universal time.",
                               localDateTime,
                               univDateTime);
            }

Я не разбираюсь, где UTC (и что это), а де не-UTC. Для ЕГЭшника это слишком сложно. Недавно гуглил, что такое все эти GMT , UTC и т.д. - нифига не понял, извините :man_shrugging:
То есть, такая запись 2023-10-23T11:48:08.879Z называется UTC, а такая 2023-07-27T08:52:44.149+02:00 - GMT? При парсинге второй параметры влияют, а при парсинге первой - нет? :thinking:
При парсинге первой всегда получается локальное время, а чтобы перевести его в GMT (без учёта пояса), надо вызвать .ToUniversalTime()?
Правильно понял?
Но я недавно вызывал .ToUniversalTime() и оно не помогало.
Пришлось делать так:

        public static DateTime ToGmt(this DateTime dateTime)
        {
            TimeSpan offset = TimeZoneInfo.FindSystemTimeZoneById("GMT Standard Time").BaseUtcOffset;
            return dateTime.ToUniversalTime().AddHours(offset.Hours);
        }

Реально, ну чё за фигня? :japanese_goblin: .ToUniversalTime() не работал. Я его точно пробовал (недели две-три назад).
А сейчас работает, почему-то :imp:

Тебе надо прочитать что такое “инженерный подход”. Его суть заключается в том, что надо вести журнал действий. Вообще это требуется для совместной эксплуатации сложных инженерных объектов разными людьми, но и в твоём случае бы помогло. Не было бы проблем сравнить то, что было две недели назад, и то, что есть сейчас, чтобы быстро и просто увидеть разницу.