On Mon, Jul 13, 2009 at 11:28 PM, Marnen Laibow-Koser<[email protected]> wrote: > > Hassan Schroeder wrote: > [...] >> And that's 100% silly. If I say that I typically get up at 7:00, it's >> totally >> irrelevant where I am. I get up at 7 in San Jose. I get up at 7 in New >> York. I get up at 7 in Frankfurt. I get up at 7 in Ubud. It's 7 hours >> after >> midnight wherever I happen to be. > > Yes -- *wherever you happen to be*. Not in some other time zone. > >> >> There is utterly no "time zone" component to the concept (and use >> case) I'm talking about. > > There absolutely is a time zone component -- namely, the local time > zone. This would be like saying (in Rubyish pseudocode: > > @hassan.set_alarm(Time.new(:hour => 7, :minute => 0, :zone => > DEFAULT_TIME_ZONE)) > # I know Time.new's syntax is not like this -- just trying for clarity. > > A clock time cannot be a useful without a time zone -- even if that time > zone is set to a sensible default, it's still *there*.
But there are definitely use cases where the time zone is NOT inherently part of the time value. I've spent quite a bit of time looking at things like this in implementing ri_cal. One set of use cases comes from the various ways RFC 2445 allows date/date-time values to be represented in icalendar data. It may be expressed in UTC or Zulu time. For example within an event might have its start time specified by: DTSTART:200907T1100000Z It may be expressed with a specific local time zone e.g. DTSTART;TZID=America/New_York:200907T14070000 It may be expressed with a floating time zone DTSTART:20090714T070000 In this last case the actual time is determined by having the time zone supplied by the user or the user's calendar application, presumably that will be the user's local time zone. Uses for floating times might be to represent when the beginning of the New Year is celebrated, which tends to happen at xxxx0101T000000 or midnight at the beginning of 1 January in each local time zone. Or expressing that I wake up, or try to, at 7:00 a.m. in whatever time zone I happen to find my body in. The last RFC value for a time attribute is just a date e.g. DTSTART:20090714 which is inherently floating with respect to time zone. That said, this discussion has been ignoring the fact that a time might not represent a time of day, but can in certain cases represent a duration, and there are differing standards on representing these. RFC2445 has a period value which represents a signed time duration, which can have week, day, hour, minute and second parts. The Duration class in ActiveSupport is similar, it represents a signed period with the same parts as are defined for Time#advance, years, months, days, hours, minutes, and seconds. But as far as I can tell, this really isn't surfaced very well, in rails durations are pretty much used as temporary results in time calculations. And some SQL implementations, MySQL for one, have time values which are really durations with hour, minute, and second parts. MySql allows such a time to represent periods longer than a day, so 132:20:00 is a valid time, although it would be a lousy time of day, except perhaps for Bill Murray's character in Ground Hog Day to use. -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Twitter: http://twitter.com/RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
