search

dart-lang / sdk

The Dart SDK, including the VM, JS and Wasm compilers, analysis, core libraries, and more.
https://dart.dev
BSD 3-Clause "New" or "Revised" License
10.23k stars 1.57k forks source link

DateTime does not support numeric time zones #34910

Open sanderAtMaxdoro opened 6 years ago

sanderAtMaxdoro commented 6 years ago

Thank you for taking the time to file an issue!

In order to route, prioritize, and act on this, please include:

Missing some or all of the above might make the issue take longer or be impossible to act on.

Is it really an issue? For general questions consider starting with Stack Overflow: https://stackoverflow.com/questions/tagged/dart

Also consider our Gitter channel for light-weight/quick discussions: https://gitter.im/dart-lang/sdk

DateTime supports either the UTC timezone or the current device timezone. Now If I get a date with timezone from the server, the server adds a timezone, as this is a date the user is entering by looking at his own wall clock, and the server adding its timezone. This is of course so that if you examine the data later, you still see that wall clock time for the user, while the timezone makes sure that the time is completely known.

Dart's DateTimes without numeric timezones however makes it impossible to show the same wall clock time for that data, as DateTime will always turn that into either UTC, to the local timezone of the device. Which means that you cannot show the data as the user has entered it.

This makes DateTime unusable for showing user-entered dates and times in countries with multiple timezones, in countries with Summertime, for user that happen to be in a different timezone when looking at the date.

I have read the time zone name argument, and how to localise it. Point is, numeric timezones do not have to be localised, and that argument is moot.

Frankly, if I had known of this limitation before the project started, I would have argued against Dart/Flutter as a proper platform for mobile development.

rich-j commented 6 years ago

Consider one of the contributed Dart packages to provide functionality missing in the standard libraries. We are very happy with Dart Time Machine. At first look it may seem complex but it's the best we've found for correctly handling dates, times, timezones, etc. It is a Dart port of the .NET Noda Time library which has been around several years. (The .NET documentation is a useful guide for the Dart version)

sanderAtMaxdoro commented 6 years ago

All the packages I looked at have support for mapping locations to a time zone, which I don't need, and these mapping files take up the bulk of the size of the distributable. Secondly, each and every package must be vetted because of security regulations. I am much better off rolling my own rather than using external packages given these constraints, hence the request for putting a reasonable minimum in the core language.

lrhn commented 6 years ago

One of the reasons Dart DateTime does not support arbitrary time zones is that it is compiled to JavaScript Date objects - which also only supports UTC and one unspecified "local" time (which the platform is supposed to provide support for).

When you start working with time zones in earnest, it gets much more complicated. You need a way to translate between those time zones, consider daylight saving time, etc. Putting that in a separate package that you have to opt-in to using, ensures that the Dart platform doesn't grow unnecessarily large when deployed as JavaScript code for the web.

sanderAtMaxdoro commented 6 years ago

On iOS, timezone support is part of the core system. If you want to compete with iOS, you need better support than wat JavaScript does support. I am not competing with javascript on the server, I am competing with native apps.

And as I said before, Dutch secure coding standards insist that I check all external packages for security issues. An external DateTime package means that I need to check this every time I use an upgraded package. This is an enormous amount of work, and it offsets any benefit I get from using an external package.

Now, if I had any benefit form the location bits (like saying Europe/Amsterdam for a UTC+1 Time zone, this might be worth it. But I don't need that support at all, the only thing I need is a proper timezone with hours, minutes and east or west or Greenwich.

So I trade an unknown amount of work and a security risk by using an external package for a known amount of work and no security risk by adding numeric timezone support myself.

maks commented 4 years ago

@sanderAtMaxdoro It's not really clear what you are asking for. In your original issue comment you have:

Now If I get a date with timezone from the server, the server adds a timezone, as this is a date the user is entering by looking at his own wall clock, and the server adding its timezone.

How do you receive this date with timezone? presumably as some sort of string?

If so are you asking for DateTime to be able to parse a numeric timezone out of a particular (ISO8601?) string format? as presumably once you have done that you can just use a wrapper class that stores that offset as described here along with the DateTime in UTC.