DateFormat time zones unimplemented

[DartBot]

Originally opened as dart-lang/sdk#10732

This issue was originally filed by bordoley...@gmail.com

---

main() {  var df = new DateFormat("EEE, d MMM yyyy HH:mm:ss z");   var date = df.parse("Tue, 15 Nov 1994 08:12:31 PST");   print (df.format(date)); // throws exception }

[DartBot]

Comment by anders-sandholm

---

cc @floitschG. Added Area-Library, Library-Core, Triaged labels.

[DartBot]

Comment by floitschG

---

cc @alan-knight. Removed Library-Core label.

[DartBot]

Comment by alan-knight

---

It's arguably related to core, since DateTime does not store a time zone, which makes it hard to format one. Is the point of this bug that time zone should be recorded and printed, or that you'd rather just have a time zone in a format specification ignored rather than throwing an UnimplementedError?

[DartBot]

This comment was originally written by bord...@gmail.com

---

My goal is to able to parse and format HTTP date strings with DateFormat. I would expect parse() to generate a correct Date object based upon the TZ in the in the source string as a UTC Date. Regarding format(), I would expect the resulting output a valid date string using GMT as the timezone.

Of course ideally, DateTime would be updated to include TZ as well.

[DartBot]

Comment by alan-knight

---

I think DateTime.parse() might be a better API for reading a format that isn't internationalized. It appears that JavaScript's Date.parse() does read dates in this format. However, the Dart DateTime.parse doesn't use that, and reads in "a subset of ISO 8601" which isn't defined.

Part of the reason timezones are unimplemented right now is that to read and correctly interpret a timezone, particularly by name, requires a great deal of data to be downloaded to a client, and we're reluctant to do that. Having just the information to read RFC822 dates wouldn't be that much, but it seems rather odd for an internationalization library to be able to read time zones, but only US ones, and only in English.

[DartBot]

Comment by alan-knight

---

Changed the title to: "DateFormat time zones unimplemented".

[DartBot]

Comment by floitschG

---

Fwiw issue dart-lang/sdk#1878 tracks the planned improvements to DateTime.parse.

[DartBot]

Comment by lrhn

---

I don't think we are expecting to add more time zone names to be recognized by DateTime.parse, so "PST" is probably not going to work, even if the input was formatted as DateTime.parse expected. This seems to be something that a specialized Date parsing package should handle.

---

Added Library-Core label.

[DartBot]

Comment by sgjesse

---

No plans to add timezone to DateTime.

---

Removed Area-Library, Library-Core labels. Added Area-Pkg, Pkg-Intl labels.

[DartBot]

Comment by alan-knight

---

Removed Type-Defect label. Added Type-Enhancement label.

[DartBot]

Comment by tlarsen4google

---

If DateTime.timeZoneName works (it produces, e.g. "CDT") in a dart:html application (compiled to Javascript even), why not at least the single "z" in DateFormat?

[DartBot]

Comment by alan-knight

---

For one thing, people might reasonably expect that

   f.parse(f.format(aDate)) == aDate

which would not be true if we included a time zone.

[JankoLancer]

Can we implement this method? Date have timezone and timezone offset, can we return this timezone?

[j0nscalet]

While the dart team is hard at work on other higher value things...

I wanted to share this in case it's helpful to anyone. I've wrote a function that formats a DateTime that includes the time zone offset details in iso8601 format.

https://gist.github.com/j0nscalet/78a6e59d1e07b885e144e19675a04d3e

[sbeitzel]

I wonder if there's an opportunity to work with the timezone package on creating a TZDateFormat to go along with its TZDateTime.

[mosuem]

Keeping this issue as a tracker for all issues around parsing and formatting time zones and time zone offsets.

[jimmyff]

Wow can't believe this still isn't implemented in 2022 🤯

Any chance of giving this some priority dart team?

[mosuem]

As stated above, the problem is mainly the large data size associated with time zones. Therefore having a separate package, such as package:timezone, is not a bad idea.

[jimmyff]

Thanks @mosuem -I think it would be worth replacing the unimplemented error with an error that directs people to the timezone package. Otherwise you'll be getting people like me ending up here forevermore!

[minias]

Wow I still can't believe this isn't running in 2023 👎👎👎👎👎

Doesn't the darts team have a desire to solve this problem?

[ristiisa]

Doesn't the darts team have a desire to solve this problem?

They are waiting for the 10y anniversary! But yeah DateTime is the worst...

[mosuem]

The Dart team cares so much about this that a member of the team is maintaining a package:timezone in his personal Github account.

The docs of package:intl should still be updated though.