Gregory's Server@mattl the only problem with ISO dates is they are all based on local time and there's no standard to specify the time zone. It's a constant source of aggravation for app that insist on storing a date instead of date time, or pre aggregating data by day, week, etc. And don't get me started on the impact of daylight savings time...
|
3 comments
 @n2burns @mattl for a date-time. A simple ISO date does not include those. For sure if your engineers decide to store the date-time for the start of day they are aggregating on that's going to work, but people seldom do that. Also if they are aggregating on anything other than UTC they could decide to decide to store the time zone separately but again that's often not the case. @enmodo @mattl Correct me if I'm wrong, but it sounds like your issue is people using the incorrect type, not the standard itself. Most programming languages have multiple number types, you shouldn't take it out on the language if someone incorrectly uses an integer. Date values shouldn't have any awareness of timezones. For example, my Date of Birth doesn't change if I move halfway around the world, even though my Time of Birth is on a different day. |
@enmodo @mattl that's not true at all. The spec includes support for Zulu time zones and UTC offsets.