2 ms·

Those are some interesting situations, but I think they can still be handled using the 3 types I mentioned. A Skype call is actually a good example of when not

by MarkMc 10y ago

Those are some interesting situations, but I think they can still be handled using the 3 types I mentioned. A Skype call is actually a good example of when not to use a data type which encapsulates 'time zone plus instance in time'. That's because there is not one but multiple time zones associated with a single instance in time - each Skype caller will have his or her own time zone. The time of the call should be treated as a pure 'instance in time' without reference to any particular time zone. When it comes to displaying the time to a particular user, you would have formatting code which takes (a) the user's time zone; (b) the user's language; (c) a format pattern; and (d) the instance in time; and returns (e) a string representation of the time for that user. If the computer's clock is based UTC it is trivial to find the duration between two 'instants in time': it's just t2 - t1. An instant in time (what I called Type 1) is independent of any calendar system so months, leap years, time zones, etc. don't matter when calculating the duration between two Type 1 values. However, in practice most system clocks are not based on UTC but rather Unix Time [1]. Due to leap seconds, such clocks do not always 'tick' in a monotonic way. So I accept that it is usually not trivial to accurately find the duration between two times. But the solution is not to burden the programmer with an extra type - instead, just add a method to the existing 'instant in time' class like this: t1.millisecsUntil(t2). To find the days in any given month, a 'date in the Gregorian calendar' class (what I call Type 2) can handle that easily - just call the daysInMonth() method. Again, no need to create new type. Easter, Islamic dates, Buddhist dates, banking days, etc. are all based on Type 2 - ie. an abstract concept of a 'day' without reference to any time zone or any particular instant in time. [1] https://en.wikipedia.org/wiki/Unix_time https://en.wikipedia.org/wiki/Unix_time

edejong 10y ago
The Skype call is always in reference to a certain perspective of 'time-of-day'. So, you'd say: I will call you at 13.00 CET, which is 14:00 GMT at my place. When we move it to the next day, it will be in reference to CET and DTS will be taken into account in CET, not in GMT. As long as humans see time as a location dependent aspect, it makes sense to inform them of the reference that has been used (being the timezone). Another way to say this is that the Skype call, or the appointment, will be scheduled at a time and timezone of someone's perspective. The other participants need to see the appointment in reference of that. The duration in milliseconds is (almost always) easy to find. However, you often want to find the duration in months, weeks, days, etc. etc. This again requires a reference timezone and calendar system. Your 'type 2' day is actually very difficult to define. For example, when I talk about the 12th of October 2016, I will see it as a time-interval in central European time. Your time-interval might be different. By the way, you can only handle the daysInMonth case. Other examples would fail: weeksInMonth, weeksInYear, hoursOfMonth, etc. etc.

by MarkMc 10y ago

edejong 10y ago

The Skype call is always in reference to a certain perspective of 'time-of-day'. So, you'd say: I will call you at 13.00 CET, which is 14:00 GMT at my place. When we move it to the next day, it will be in reference to CET and DTS will be taken into account in CET, not in GMT. As long as humans see time as a location dependent aspect, it makes sense to inform them of the reference that has been used (being the timezone). Another way to say this is that the Skype call, or the appointment, will be scheduled at a time and timezone of someone's perspective. The other participants need to see the appointment in reference of that. The duration in milliseconds is (almost always) easy to find. However, you often want to find the duration in months, weeks, days, etc. etc. This again requires a reference timezone and calendar system. Your 'type 2' day is actually very difficult to define. For example, when I talk about the 12th of October 2016, I will see it as a time-interval in central European time. Your time-interval might be different. By the way, you can only handle the daysInMonth case. Other examples would fail: weeksInMonth, weeksInYear, hoursOfMonth, etc. etc.