Time is a bit like character sets, in that you can more or less get something useful by guesswork on the data, but that’s not safe for key systems.
A place, or system, has a timezone such as “Europe/London”. A time should either have a time-offset (eg. +0100 or BST) stored with it, OR it can be assumed to be in the timezone for the system running it.
What is important is that when converting datetimes (without explicit offsets) to exact times in seconds (UNIX time_t), that you convert using the offset that was true on the date, not the current offset.
Like UTF-8, you can’t always tell by looking what a time means. Don’t use the MSSQL DATEDIFF() function as it appears to use the current offset (ie GMT) rather than the offset which was true at the given date (BST). This is a subtle issue, and long really bites if converting DATETIME to UNIX time.
The moral of the story is, like with character sets, to use a damn library, and that just because the output looks correct, doesn’t mean it is.
0 Responses
Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.