4 ms·

> 1) You're exposing some internal logic or data structure of the system in the resource Not following. What internal logic or data structure? > 2) You're rem

> 1) You're exposing some internal logic or data structure of the system in the resource Not following. What internal logic or data structure? > 2) You're removing information on time zone This is [almost] always a good thing. Obviously there's personal preference involved here, but I've never seen a system where storing the TZ turned out to be a good idea (not that I've seen all that many systems).

Marazan 14y ago
Any process that involves date/times and doesn't involve date/times being stored and processed as UTC dates is the wrong solution. As the final step on the presentation layer you can convert them into whatever wacky TZ you want but passing dates back and forward to the server in non-UTC format is fast track to Insanityland
- lotsofcows 14y ago
  While I generally agree with you, the OP was using unix time - UTCiness is built in.
buro9 14y ago
> This is [almost] always a good thing. Obviously there's personal preference involved here, but I've never seen a system where storing the TZ turned out to be a good idea (not that I've seen all that many systems). Assuming that time is important, perhaps Google Calendar is a good example of timezones and datetimes as strings: https://developers.google.com/google-apps/calendar/v3/reference/events https://developers.google.com/google-apps/calendar/v3/refere... I guess it depends on what you're doing with the data... if it's just "created" then it matters less. But if you're dealing with storing an event in time, it usually occurs in a place that has timezone data... boarding a plane in one timezone and landing in another, a meeting where attendees dial-in from multiple timezones and you need to alert them all at the right time and visually indicate that. Timezones aren't trivial, and the system might store UTC under the hood, but throwing them out universally and trusting every client to get it right seems less of a good idea than handling them and taking care of that on the API side.
- mnarayan01 14y ago
  It looks to me like you can set what TZ you want to retrieve dates in when performing queries, with the default being the TZ associated with the calender; this is substantially different than simply returning times with whatever arbitrary TZ was used when creating the record.
  - buro9 14y ago
    Inserts on that API also insist on timezones, because timezones are actually important for events that occur in a time and place.

Marazan 14y ago

Any process that involves date/times and doesn't involve date/times being stored and processed as UTC dates is the wrong solution. As the final step on the presentation layer you can convert them into whatever wacky TZ you want but passing dates back and forward to the server in non-UTC format is fast track to Insanityland

lotsofcows 14y ago
While I generally agree with you, the OP was using unix time - UTCiness is built in.

buro9 14y ago

> This is [almost] always a good thing. Obviously there's personal preference involved here, but I've never seen a system where storing the TZ turned out to be a good idea (not that I've seen all that many systems). Assuming that time is important, perhaps Google Calendar is a good example of timezones and datetimes as strings: https://developers.google.com/google-apps/calendar/v3/reference/events https://developers.google.com/google-apps/calendar/v3/refere... I guess it depends on what you're doing with the data... if it's just "created" then it matters less. But if you're dealing with storing an event in time, it usually occurs in a place that has timezone data... boarding a plane in one timezone and landing in another, a meeting where attendees dial-in from multiple timezones and you need to alert them all at the right time and visually indicate that. Timezones aren't trivial, and the system might store UTC under the hood, but throwing them out universally and trusting every client to get it right seems less of a good idea than handling them and taking care of that on the API side.

mnarayan01 14y ago
It looks to me like you can set what TZ you want to retrieve dates in when performing queries, with the default being the TZ associated with the calender; this is substantially different than simply returning times with whatever arbitrary TZ was used when creating the record.
- buro9 14y ago
  Inserts on that API also insist on timezones, because timezones are actually important for events that occur in a time and place.