On 2010-04-27 07:22:12 -0400, SHOO <[email protected]> said:
Thanks to your response. I think that handling DST is necessary too. But I am unfamiliar about DST so that people of the Ascii character string zone are unfamiliar about multi-byte character string. (I live in Japan which does not use DST.) I may not exactly recognize bugs even if I implemented it. I want to leave the implementation to other people who knows DST well.
The problem with DST (and time zones in general) is that it's subject to change. DST dates were changed a couple of years ago here in Canada and in the United States; operating system vendors made a patch for this and things went smoothy (for the most part) for applications using the OS to know about DST. This can get more complicated though: for Israel (post 2005) you'll need to follow the hebrew calendar[1], and before 2005 it's mostly arbitrary.
I think timezones and DST management are better left to the OS. What is most important to have is a way to convert local dates and times to UTC and the reverse, and to determine the local UTC offset for a given time. I'd leave the rest to other libraries, or OS-specific APIs.
[1]: http://en.wikipedia.org/wiki/Israel_Summer_Time -- Michel Fortin [email protected] http://michelf.com/
