4 ms·

My experience is that for most applications, programmers really only need to understand 3 types: 1. An instant in time - often represented as an integer number

by MarkMc 10y ago

My experience is that for most applications, programmers really only need to understand 3 types: 1. An instant in time - often represented as an integer number of milliseconds since January 1, 1970. 2. A date in the Gregorian calendar. This could also be an integer offset from a particular day, but it's better to encapsulate it in a class that allows you to add days or months, get the number of days between two dates, etc. 3. A timezone which is necessary to convert between the two types mentioned above. Java has default classes to represent Types 1 and 3, but is missing a simple class for Type 2. So I designed one myself: http://calendardate.sourceforge.net http://calendardate.sourceforge.net

zAy0LfpBZLC8mAC 10y ago
> 1. An instant in time - often represented as an integer number of milliseconds since January 1, 1970. That's already an undefined statement ;-) I mean, I guess you are actually aware of it, but that's not actually an instant in time, that's about 24 different spans of time, each 86400000 milliseconds long.
- inimino 10y ago
  It took me a while to figure out what you are pointing out. GP left out the time and timezone, but we still recognize that date as shorthand referring to the Unix epoch.
- MarkMc 10y ago
  Whoops sorry I should have said January 1,1970 GMT!
dlubarov 10y ago
Did you see Java 8's java.time classes? There's LocalDateTime for type 2, and Instant which is like a much improved Date. Both obviously Joda inspired.
- MarkMc 10y ago
  Thanks - I didn't know Java 8 had incorporated Joda time. Actually LocalDate is a better representation for Type 2 because it doesn't encapsulate minutes, hours or seconds. This would make it ideal to represent "John's birthday" or "date on which the customer repaid loan". In fact, I'm disappointed that Java has incorporated Joda time - new Java programmers will now need to crawl over a huge pile of time-based classes to pick out the ones they need, when for 99% of cases only the same 3 types are necessary. How many of these novice users will incorrectly use LocalDateTime to represent Type 1?
  - kedean 10y ago
    To be fair, they didn't literally incorporate Joda, the new library is "heavily inspired" by it. It has way fewer classes, organized into a very sensibly named hierarchy.
    - LgWoodenBadger 10y ago
      The Joda-time author (jointly) led the JSR for this. http://www.oracle.com/technetwork/articles/java/jf14-date-time-2125367.html http://www.oracle.com/technetwork/articles/java/jf14-date-ti...
      - dlubarov 10y ago
        Yes, but the java.time package is significantly smaller, and much improved in my opinion. For example, Joda has a few mutable structures, while java.time is 100% immutable. I still don't like how you can do things like Instant.from(DayOfWeek.MONDAY) (which results in a runtime exception), but at least at least it's slightly more type-safe than Joda, wherein all the conversion methods take an Object parameter.
taejo 10y ago
> 1. An instant in time - often represented as an integer number of milliseconds since January 1, 1970. POSIX time is actually not the number of seconds since 00:00 UTC on January 1, 1970, but the 864000 times the number of days since January 1, 1970, plus the number of seconds since the start of the current day. See "1. There are always 24 hours in a day" (or rather, there are always 60 seconds in a minute, since the leap second makes the last minute/hour of the day longer, so there are still 24 hours in the day)
- MarkMc 10y ago
  OK yes, it's more common to use POSIX 'ticks' to represent an instant in time. The point is: Type 1 is an instant in time, is independent of any timezone or calendar system, and is usually represented by an integer.
  - deathanatos 10y ago
    > OK yes, it's more common to use POSIX 'ticks' to represent an instant in time. The point is: Type 1 is an instant in time I'm not sure what a "tick" is, but POSIX time often purports to be the number of seconds (or similar) since 1970, (and thus, represent an instant in time) but in practice it isn't; that's the point of the parent poster: it's precisely the definition that he or she gave. (It's the number of days times a constant, etc.) While usually POSIX time represents an instant in time, it becomes ambiguous during leap seconds, and duration calculations with POSIX times will almost invariably be just arithmetic on the underlying value, which is going to be wrong over certain intervals (any interval crossing a leap second). For the most part, nobody notices, but this is where and why weird bugs crop up.
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.

by MarkMc 10y ago

zAy0LfpBZLC8mAC 10y ago

> 1. An instant in time - often represented as an integer number of milliseconds since January 1, 1970. That's already an undefined statement ;-) I mean, I guess you are actually aware of it, but that's not actually an instant in time, that's about 24 different spans of time, each 86400000 milliseconds long.

inimino 10y ago
It took me a while to figure out what you are pointing out. GP left out the time and timezone, but we still recognize that date as shorthand referring to the Unix epoch.
MarkMc 10y ago
Whoops sorry I should have said January 1,1970 GMT!

dlubarov 10y ago

Did you see Java 8's java.time classes? There's LocalDateTime for type 2, and Instant which is like a much improved Date. Both obviously Joda inspired.

MarkMc 10y ago
Thanks - I didn't know Java 8 had incorporated Joda time. Actually LocalDate is a better representation for Type 2 because it doesn't encapsulate minutes, hours or seconds. This would make it ideal to represent "John's birthday" or "date on which the customer repaid loan". In fact, I'm disappointed that Java has incorporated Joda time - new Java programmers will now need to crawl over a huge pile of time-based classes to pick out the ones they need, when for 99% of cases only the same 3 types are necessary. How many of these novice users will incorrectly use LocalDateTime to represent Type 1?
- kedean 10y ago
  To be fair, they didn't literally incorporate Joda, the new library is "heavily inspired" by it. It has way fewer classes, organized into a very sensibly named hierarchy.
  - LgWoodenBadger 10y ago
    The Joda-time author (jointly) led the JSR for this. http://www.oracle.com/technetwork/articles/java/jf14-date-time-2125367.html http://www.oracle.com/technetwork/articles/java/jf14-date-ti...
    - dlubarov 10y ago
      Yes, but the java.time package is significantly smaller, and much improved in my opinion. For example, Joda has a few mutable structures, while java.time is 100% immutable. I still don't like how you can do things like Instant.from(DayOfWeek.MONDAY) (which results in a runtime exception), but at least at least it's slightly more type-safe than Joda, wherein all the conversion methods take an Object parameter.

taejo 10y ago

> 1. An instant in time - often represented as an integer number of milliseconds since January 1, 1970. POSIX time is actually not the number of seconds since 00:00 UTC on January 1, 1970, but the 864000 times the number of days since January 1, 1970, plus the number of seconds since the start of the current day. See "1. There are always 24 hours in a day" (or rather, there are always 60 seconds in a minute, since the leap second makes the last minute/hour of the day longer, so there are still 24 hours in the day)

MarkMc 10y ago
OK yes, it's more common to use POSIX 'ticks' to represent an instant in time. The point is: Type 1 is an instant in time, is independent of any timezone or calendar system, and is usually represented by an integer.
- deathanatos 10y ago
  > OK yes, it's more common to use POSIX 'ticks' to represent an instant in time. The point is: Type 1 is an instant in time I'm not sure what a "tick" is, but POSIX time often purports to be the number of seconds (or similar) since 1970, (and thus, represent an instant in time) but in practice it isn't; that's the point of the parent poster: it's precisely the definition that he or she gave. (It's the number of days times a constant, etc.) While usually POSIX time represents an instant in time, it becomes ambiguous during leap seconds, and duration calculations with POSIX times will almost invariably be just arithmetic on the underlying value, which is going to be wrong over certain intervals (any interval crossing a leap second). For the most part, nobody notices, but this is where and why weird bugs crop up.

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.