Trivia: "Unix time" is not seconds since midnight January 1, 1970 UTC. It in fact represents the number of full days since January 1, 1972 UTC, plus 730, times 86400, plus the number of seconds since midnight. Due to this definition, it is not monotonic, as it may occasionally have discontinuities of 1 second (in either direction!) due to leap seconds.
Best is to just count seconds since some epoch (e.g. Unix time based on TAI rather than UTC), but not many systems actually do this.
I never really got what the problem was, but apparently someone had been careless about comparing times on some transaction which ended up giving a client a bad day.
This was some time ago, and if this stuff actually matters to you you probably know how to deal with it.
It's also important to note that ISO 8601 format is the default format that Date object serialize to. Try it new Date().toJSON()
RFC3339 defines a subset that is only the sane tinestamp format most people probably think of when they think ISO8601. It's a good alternative, although a lot of the time UNIX timestamps are honestly the most convenient option for everyone.
Source: spent a bunch of time designing a public API and thinking about this.
What makes you use signed 32-bit Integer for Unix timestamp in this age and day? I work with embedded systems and use Unix timestamp extensively, but never have I found any serious reason to use it as int32_t.
Let's do the same for time - no more time zones, make the base unit a day and then it can be divided or multiplied in the 10s, 100s, 1000s, etc.
Abolishing time zones isn't necessarily a good idea.
new Date('2016-02-11') !== new Date(2016,1,11)
(╯°□°)╯︵ ┻━┻
> new Date(2016,1,11)
Thu Feb 11 2016 00:00:00 GMT-0800 (PST)
> new Date('2016-02-11')
Wed Feb 10 2016 16:00:00 GMT-0800 (PST)