4 ms·

I think the following ingredients are minimally necessary for normal day-to-day stuff: 1. For events in the past, a timestamp 2. For events in the future, a d

by edejong 10y ago

I think the following ingredients are minimally necessary for normal day-to-day stuff: 1. For events in the past, a timestamp 2. For events in the future, a date/time pair with precision at least milliseconds and a timezone. 3. An ISO 8601 serialization/deserialization method 4. A duration type, which denotes a number of 'hours/minutes/seconds/days/weeks'. 5. A partial representation of date, to denote repeating events or events which last a whole day. The partial representation should optionally include a timezone. This allows me to say: '5th of May', or '22nd of November 1980, in CEST'. For calculations of dates and times, it is very useful to have a notion of time intervals, durations of time and weekdays.

detaro 10y ago
Good list, sadly many (most?) popular languages have difficulties fulfilling it, sometimes even if you include third-party libraries...
MarkMc 10y ago
> For events in the future, a date/time pair with precision at least milliseconds and a timezone. Hmmm...Can you give an example where that would be used? I'm thinking of a user who wants to be woken up at 7am even if they change their timezone. But that wouldn't require millisecond precision. > A duration type, which denotes a number of 'hours/minutes/seconds/days/weeks'.. For calculations of dates and times, it is very useful to have a notion of time intervals, durations of time and weekdays. Couldn't you do that with the first two types I mentioned? With two instances of Type 1 it's trivial to count the number of milliseconds between them. With two instances of Type 2 you can have d1.daysUntil(d2) or dq.monthsUntil(d2) etc. > This allows me to say: '5th of May'... Is that common enough and complicated enough to warrant an extra type? When I write code to process credit card payments, I just record the card expiry as two integers: expMonth and expYear. When I want to check if the card is expired I just create a Type 2 instance representing the last day of the month. Seems to me I could do something similar for 'repeat on 5 May'.
- tomjen3 10y ago
  For the first example, a skype meeting with participants on both sides of the equator, or even just in countries where one has ended daylight savings time and the other hasn't yet. That may seem like a special case, but it is relatively common, it might also matter for normal business meetings in a foreign country - UK time is an hour behind France, so if you are a UK business man trying to have a meeting in Paris, you need to take time zones into account. It is never trivial to calculate the duration between two times, because you may have to take into account leap years, leap seconds, months that does not have the same number of days, etc, not to mention if they are in two different timezones. That doesn't mean it isn't possible, but it is not trivial. What is the last day of the month? That depends on the month, and if that is February it also depends on the current year. If you need to process credit cards, you might need to know the last banking day of the month, which could be quite early during e.g easter. BTW to know when easter falls, your dating system needs to know about the lunar calendar. This doesn't even begin to touch what happens in countries that celebrate Ramadahn.
  - 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

by edejong 10y ago

detaro 10y ago

Good list, sadly many (most?) popular languages have difficulties fulfilling it, sometimes even if you include third-party libraries...

MarkMc 10y ago

> For events in the future, a date/time pair with precision at least milliseconds and a timezone. Hmmm...Can you give an example where that would be used? I'm thinking of a user who wants to be woken up at 7am even if they change their timezone. But that wouldn't require millisecond precision. > A duration type, which denotes a number of 'hours/minutes/seconds/days/weeks'.. For calculations of dates and times, it is very useful to have a notion of time intervals, durations of time and weekdays. Couldn't you do that with the first two types I mentioned? With two instances of Type 1 it's trivial to count the number of milliseconds between them. With two instances of Type 2 you can have d1.daysUntil(d2) or dq.monthsUntil(d2) etc. > This allows me to say: '5th of May'... Is that common enough and complicated enough to warrant an extra type? When I write code to process credit card payments, I just record the card expiry as two integers: expMonth and expYear. When I want to check if the card is expired I just create a Type 2 instance representing the last day of the month. Seems to me I could do something similar for 'repeat on 5 May'.

tomjen3 10y ago
For the first example, a skype meeting with participants on both sides of the equator, or even just in countries where one has ended daylight savings time and the other hasn't yet. That may seem like a special case, but it is relatively common, it might also matter for normal business meetings in a foreign country - UK time is an hour behind France, so if you are a UK business man trying to have a meeting in Paris, you need to take time zones into account. It is never trivial to calculate the duration between two times, because you may have to take into account leap years, leap seconds, months that does not have the same number of days, etc, not to mention if they are in two different timezones. That doesn't mean it isn't possible, but it is not trivial. What is the last day of the month? That depends on the month, and if that is February it also depends on the current year. If you need to process credit cards, you might need to know the last banking day of the month, which could be quite early during e.g easter. BTW to know when easter falls, your dating system needs to know about the lunar calendar. This doesn't even begin to touch what happens in countries that celebrate Ramadahn.
- 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