On Tuesday, December 27, 2011 11:19:03 Kagamin wrote: > > The core issue with not carrying around a time zone is that you > > get conversion problems. People do dumb stuff like convert > > time_t values from UTC to local time and back again, which > > causes all kinds of bugs. > > Can you elaborate?
1. Any time you do a conversion of any kind, you risk screwing it up. The less converting you do, the better. 2. With regards to time, DST is a killer. The reason for this is the fact that in the spring, one hour gets skipped, and in the fall one hour happens twice. So, for example, let's say that in a particular time zone, at 2 am on March 3rd, the time goes to 3 am to apply DST. That means that the times of 2 am up to (but not including) 3 am do not exist. So, if you have the time 2:30 am in local time, what time is that in UTC? It's likely that the time code will assume that it's really 3:30 am, but the time that you're trying to convert doesn't technically exist, so there is not actually a right answer. On the other hand, let's say that on 2 am on October 30th, the time falls back to 1:00 am taking that time zone out of DST. That means that the times of 1 am up to (but not including) 2 am happen twice. So, if you have the time 1:30 am in local time, what time is it in UTC? You can't know. It could be either. The time code is going to have to pick one or the other, but since 1:30 am is non- unique, it's not necessarily going to have the behavior which is correct for your program. However, UTC can _always_ be correctly converted to other time zones whether they have DST or not. This is because UTC does not have DST and therefore does not have hours that don't exist or hours that happen twice. All of its times are unique. So, if you want to deal with time accurately and reliably, you need to always keep the time in UTC until you _need_ to convert it to local time (typically for display purposes but also for things like if you need to know something along the lines of what year that time is in in the local time zone). Code which converts time back and forth between UTC and local time is asking for trouble. Even if it gets all of the conversions correct (or at least as correct as possible), it's going to have issues whenever a DST change occurs. That's one of the reasons why non-Windows OSes typically want to put the system clock in UTC and what it's so horrible that Windows normally puts the system clock in local time (another is the fact that applying DST can make it so that files from a few minutes ago are suddenly in the future if the file timestamps are in local time). Where I work, we ended up with a bug where when you rewinded video and you were east of UTC, it would rewind one hour too far for each hour east of UTC that you were (so 2 hours east of UTC would rewind 2 hours and 1 second instead of 1 second). It turns out that the code had been converting a time value to UTC from local time when it was already in UTC (or it might have been the other way around - I don't recall exactly which at the moment). And that meant that it was subtracting the UTC offset from the time, causing it to go back too far. The only reason that we hadn't seen it in the US was because west of UTC, the time would have been in the future, which it couldn't do, so it ended up rewinding properly. Had that code completely avoided all of the time conversions that it was doing, it wouldn't have had any issues like that. And the fact that the bug only manifested in certain time zones (and _not_ the time zones that the code was being developed in) made it that much worse. Times should be kept in UTC as much as possible and converted as little as possible. Anything else is asking for trouble. That's also one reason why it's good to have times be objects rather than naked numbers. It reduces the risk of people converting them incorrectly. SysTime mostly avoids the whole issue by encapsulating the time (in UTC) with a time zone, making it so that it generally "just works." - Jonathan M Davis