You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Option withInternetDateTime is composed and contains {{withColonSeparatorInTimeZone }}amongst other things. The expected behavior for formatting a date into a String is reflected in the Example Column above.
This only applies for zero offsets (where Z would be appropriate), but because this is showing inconsistent behavior in documentation and {{ISO8601DateFormatter }}Implementation, I decided to open this bug.
If requested, I can look through the source code and open a pull request, if I manage to find the underlying issue here.
The text was updated successfully, but these errors were encountered:
Environment
Xcode 10.1
Mac OSX 10.13.6
Swift 4.2
Additional Detail from JIRA
md5: 7a12b63531bd9c010297e479a0d72ba9
Issue Description:
ISO8601DateFormatter shows unexpected and against-its-documentation behavior related to numeric time zone offset (ref. RFC 3339).
From the
ISO8601DateFormatter.Options
Documentation:2016-06-13T16:00:00+00:00
The Option
withInternetDateTime
is composed and contains {{withColonSeparatorInTimeZone }}amongst other things. The expected behavior for formatting a date into a String is reflected in the Example Column above.Actual Behavior:
Figure 1 -
ISO8601DateFormatter
Even though
Z
stands for+00:00
, this is not according to the documentation and/or the specified {{ISO8601DateFormatter.Options }}value.Same applies for Figure 2, the underlying DateFormatter
Figure 2 -
DateFormatter
ZZZZZ
is expected to output the "long" numeric time zone offset. ShowingZ
is inconsistent with actual offset behavior.To show even more inconsistency, Figure 3 would expect the same behavior as above, but results in this:
Figure 3 -
DateFormatter
This only applies for zero offsets (where Z would be appropriate), but because this is showing inconsistent behavior in documentation and {{ISO8601DateFormatter }}Implementation, I decided to open this bug.
If requested, I can look through the source code and open a pull request, if I manage to find the underlying issue here.
The text was updated successfully, but these errors were encountered: