5 ms·

I don't understand. Your software works for months with 28 or 30 or 31 days. Why does it break for months with 29 days? I think unless you're messing with non-

by nandemo 15y ago

I don't understand. Your software works for months with 28 or 30 or 31 days. Why does it break for months with 29 days? I think unless you're messing with non-Gregorian calendars, this is a solved problem. Am I missing something?

keypusher 15y ago
One of the many issues I saw today was around converting times to and from different formats. Let's say you have a timestamp in epoch, and you want to calculate a year long offset. You add seconds_in_year to your epoch time,, and call your date conversion library to get some kind of iso date (dd-mm-yyyy). Yes, it's wrong because seconds_in_year is not a constant, but this stuff sneaks its way into a large codebase and nobody realizes because all the tests pass until it's leap day. This is only the beginning, there are so many possible issues related to an edge case like this, while it might be a "solved problem" that doesn't mean it's something developers are thinking about every day. And don't even get me started on daylight savings time...
- RandallBrown 15y ago
  yeah throw in daylight savings time and time zones and it becomes almost unmanageable.
tazzy531 15y ago
Time in distributed cloud computing gets very complicated and very critical. Google has an interesting post on how they handled the Leap Second in 2008: http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html http://googleblog.blogspot.com/2011/09/time-technology-and-l...
lysium 15y ago
Although time is an important data in most applications, there is only poor library support for it. Most languages don't even have a data type for time! For example, the system call gettimeofday(2) does only return the seconds since Jan 1, 1970 (the 'epoch'), the time zone and the daylight saving time correction. No day, no month, no year. For this, you have to call some other function, eg. libc' localtime(3). libc's time(3) function says it returns the number of seconds since the epoch, but it ignores leap seconds, so it actually does not return the number of seconds since the epoch (since there have been several leap seconds since the epoch). Even if you use localtime(3) to get the actual wall clock hour and minutes, you are left on your own from there. Want to have a time point two hours from now? Do your own math, but watch out for the end of the day, which might also be the end of the month and/or the end of the year. One month from now? Do your own math, but watch out for months that have less days than your current month. You may want to resort to do calculations only in seconds since the epoch, but how many seconds are in a month? Depends on the month (and the year as we've just learned!). In a year? Depends on the year (Is it a leap year? Was / will be there a leap second? Do you have to care about leap seconds?). I just picked the C language because it is so prevalent. Other languages have their own issues or inherit them from C. In Python, for example, there is a timedelta object, but it can only handle days, seconds, and microseconds, so you still cannot calculate the date one month from now or one year ago. I find it unbelievably funny that it's 2012 and we still have to deal with this 'solved problem'. Turns out, it is not solved at all.
- aptwebapps 15y ago
  It seems as though you're talking about core libraries or built in functionality of a language. But for what it's worth, if you're using Python there is this: http://labix.org/python-dateutil http://labix.org/python-dateutil
- thwarted 15y ago
  libc's time(3) function says it returns the number of seconds since the epoch, but it ignores leap seconds, so it actually does not return the number of seconds since the epoch (since there have been several leap seconds since the epoch). It returns the number of actual seconds that have elapsed since the epoch, the only way to do this is to ignore leap seconds. When leap seconds occur, they don't actually exist, they just change the offset to keep things in sync. Every second the time(3) function returns exists uniquely and none are skipped, there are no ambiguous values, which you can't say if leap seconds were not ignored.
  - obtu 15y ago
    Nope, Unix time is aligned on UTC days, which means it jumps back by one when a leap second is inserted (and would jump forward when one is deleted): https://en.wikipedia.org/wiki/Unix_time https://en.wikipedia.org/wiki/Unix_time
    - thwarted 15y ago
      Ah, well I stand corrected. That being said, it seems that UNIX time doesn't take leap seconds into account physically, but they are logically visible when viewing the change over time.
- obtu 15y ago
  All of these are handled by offloading the problem to a good library. It would be dumb to handle the 30/31 months oneself, failing to take everything else into account.
  - lysium 15y ago
masto 15y ago
I just had to deal with this yesterday: sprintf("%04d-%02d-%02d", $dt_now->year()-1, $dt_now->month(), $dt_now->day()); Yes, it's a solved problem, yes, that's totally insane and wrong, yes, the guy who did it was a dummy, but I get the feeling that a lot of people writing comments like this have never had the experience of working on a large code base that has had many different developers over time. This particular beauty was introduced two years ago by a temporary contractor brought in by management to "help out" during a period of particular time pressure. He only lasted about a month, but in that time managed to introduce a line of code that would crap out on a leap day. Fortunately, it was only in a unit test, so the result was our automated builds failing, rather than a production outage. But I'm not so quick to judge others these days.

by nandemo 15y ago

keypusher 15y ago

One of the many issues I saw today was around converting times to and from different formats. Let's say you have a timestamp in epoch, and you want to calculate a year long offset. You add seconds_in_year to your epoch time,, and call your date conversion library to get some kind of iso date (dd-mm-yyyy). Yes, it's wrong because seconds_in_year is not a constant, but this stuff sneaks its way into a large codebase and nobody realizes because all the tests pass until it's leap day. This is only the beginning, there are so many possible issues related to an edge case like this, while it might be a "solved problem" that doesn't mean it's something developers are thinking about every day. And don't even get me started on daylight savings time...

RandallBrown 15y ago
yeah throw in daylight savings time and time zones and it becomes almost unmanageable.

tazzy531 15y ago

Time in distributed cloud computing gets very complicated and very critical. Google has an interesting post on how they handled the Leap Second in 2008: http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html http://googleblog.blogspot.com/2011/09/time-technology-and-l...

lysium 15y ago

Although time is an important data in most applications, there is only poor library support for it. Most languages don't even have a data type for time! For example, the system call gettimeofday(2) does only return the seconds since Jan 1, 1970 (the 'epoch'), the time zone and the daylight saving time correction. No day, no month, no year. For this, you have to call some other function, eg. libc' localtime(3). libc's time(3) function says it returns the number of seconds since the epoch, but it ignores leap seconds, so it actually does not return the number of seconds since the epoch (since there have been several leap seconds since the epoch). Even if you use localtime(3) to get the actual wall clock hour and minutes, you are left on your own from there. Want to have a time point two hours from now? Do your own math, but watch out for the end of the day, which might also be the end of the month and/or the end of the year. One month from now? Do your own math, but watch out for months that have less days than your current month. You may want to resort to do calculations only in seconds since the epoch, but how many seconds are in a month? Depends on the month (and the year as we've just learned!). In a year? Depends on the year (Is it a leap year? Was / will be there a leap second? Do you have to care about leap seconds?). I just picked the C language because it is so prevalent. Other languages have their own issues or inherit them from C. In Python, for example, there is a timedelta object, but it can only handle days, seconds, and microseconds, so you still cannot calculate the date one month from now or one year ago. I find it unbelievably funny that it's 2012 and we still have to deal with this 'solved problem'. Turns out, it is not solved at all.

aptwebapps 15y ago
It seems as though you're talking about core libraries or built in functionality of a language. But for what it's worth, if you're using Python there is this: http://labix.org/python-dateutil http://labix.org/python-dateutil
thwarted 15y ago
libc's time(3) function says it returns the number of seconds since the epoch, but it ignores leap seconds, so it actually does not return the number of seconds since the epoch (since there have been several leap seconds since the epoch). It returns the number of actual seconds that have elapsed since the epoch, the only way to do this is to ignore leap seconds. When leap seconds occur, they don't actually exist, they just change the offset to keep things in sync. Every second the time(3) function returns exists uniquely and none are skipped, there are no ambiguous values, which you can't say if leap seconds were not ignored.
- obtu 15y ago
  Nope, Unix time is aligned on UTC days, which means it jumps back by one when a leap second is inserted (and would jump forward when one is deleted): https://en.wikipedia.org/wiki/Unix_time https://en.wikipedia.org/wiki/Unix_time
  - thwarted 15y ago
    Ah, well I stand corrected. That being said, it seems that UNIX time doesn't take leap seconds into account physically, but they are logically visible when viewing the change over time.
obtu 15y ago
All of these are handled by offloading the problem to a good library. It would be dumb to handle the 30/31 months oneself, failing to take everything else into account.
- lysium 15y ago

masto 15y ago

I just had to deal with this yesterday: sprintf("%04d-%02d-%02d", $dt_now->year()-1, $dt_now->month(), $dt_now->day()); Yes, it's a solved problem, yes, that's totally insane and wrong, yes, the guy who did it was a dummy, but I get the feeling that a lot of people writing comments like this have never had the experience of working on a large code base that has had many different developers over time. This particular beauty was introduced two years ago by a temporary contractor brought in by management to "help out" during a period of particular time pressure. He only lasted about a month, but in that time managed to introduce a line of code that would crap out on a leap day. Fortunately, it was only in a unit test, so the result was our automated builds failing, rather than a production outage. But I'm not so quick to judge others these days.