Is there a reason why UTC times add " UTC" instead of ending with the "Z", following ISO 8601?
Brian FrankWed 1 Apr 2015
All datetimes end in a timezone for consistency. The "Z" really means zero offset from UTC, but it doesn't actually mean that the datetime is in UTC, it could also be the London timezone for example.
Brian FrankThu 2 Apr 2015
Shawn pointed out that in SkySpark I was actually dropping the timezone if and only if it was UTC, so its a simple ISO 8601 datetime. Any opinions on if we standardize that behavior? Or we just say you always put a timezone on the end even if its UTC and I can fix my code.
Brian FrankFri 3 Apr 2015
Actually the docs already reflect that UTC is optional. From Notes section in Zinc chapter:
DateTime scalars are encoded using both offset and the timezone name:
2010-11-28T07:23:02.773-08:00 Los_Angeles // negative offset and timezone
2010-11-28T23:19:29.741+08:00 Taipei // positive offset and timezone
2010-11-28T18:21:58+03:00 GMT-3 // timezone may include '-'
2010-11-28T12:22:27-03:00 GMT+3 // timezone may include '+'
2010-01-08T05:00:00Z UTC // UTC example
2010-01-08T05:00:00Z // UTC may omit timezone name
Shawn Jacobson Wed 1 Apr 2015
Is there a reason why UTC times add " UTC" instead of ending with the "Z", following ISO 8601?
Brian Frank Wed 1 Apr 2015
All datetimes end in a timezone for consistency. The "Z" really means zero offset from UTC, but it doesn't actually mean that the datetime is in UTC, it could also be the London timezone for example.
Brian Frank Thu 2 Apr 2015
Shawn pointed out that in SkySpark I was actually dropping the timezone if and only if it was UTC, so its a simple ISO 8601 datetime. Any opinions on if we standardize that behavior? Or we just say you always put a timezone on the end even if its UTC and I can fix my code.
Brian Frank Fri 3 Apr 2015
Actually the docs already reflect that UTC is optional. From Notes section in Zinc chapter:
DateTime scalars are encoded using both offset and the timezone name: