[ruby-core:22892] Ruby Time
valodzka
http://github.com/valodzka/time2/tree/master
I would like to hear your thoughts concerning it, and first of all -
whether there should be it a part of core or not?
Nobuyoshi Nakada
At Sun, 15 Mar 2009 08:33:32 +0900,
valodzka wrote in [ruby-core:22892]:
Do you mean Time objects should have each own timezone info?
I'd agree the idea, but distribution and maintenance of the
zoneinfo feel terrible.
--
Nobu Nakada
mathew
I agree with the fundamental idea, that any date and/or time must always have a time zone associated with it.
However, iIt appears that you are still using "seconds from epoch" for internal storage and manipulation, which means there's still some fundamental breakage.
If we're going to have a new time/date implementation, I'd like to see one that actually deals with leap seconds properly when the OS supports it, i.e. has seconds that are always a second in duration.
mathew
[ http://lpar.ath0.com/2009/03/16/chronological-pitfalls/ ]
Tanaka Akira
valodzka <valo...@gmail.com> writes:
I think Ruby should not include timezone database because
its maintainance.
However it may be considerable to extend Time to hold arbitrary time
offset from UTC, as DateTime:
p DateTime.new(2009,1,1,0,0,0,Rational(9,24))
#=> #<DateTime: 2009-01-01T00:00:00+09:00 (19638657/8,3/8,2299161)>
p DateTime.new(2009,1,1,0,0,0,-Rational(5,24))
#=> #<DateTime: 2009-01-01T00:00:00-05:00 (58915985/24,-5/24,2299161)>
The fixed time offset doesn't need timezone database. So it
has no maintainance problem.
If it is implemented, a time in a timezone can be
reprensented using a Time object with corresponding time
offset.
The time offset of "time + sec" will be same as as
the "time" which may not be correct in the timezone, though.
--
Tanaka Akira
valodzka
> However, iIt appears that you are still using "seconds from epoch" for
> internal storage and manipulation, which means there's still some
> fundamental breakage.
>
> If we're going to have a new time/date implementation, I'd like to see one
> that actually deals with leap seconds properly when the OS supports it, i.e.
> has seconds that are always a second in duration.
>
You are not quite right. Yes, it uses "seconds from epoch" for
internal representation, but it doesn't mean library can't handle
leap seconds. You should just use right timezone. I've added example
with leap second in README. About future dates and leap seconds: tz
database cannot be changed untill program work, so relation time_t <->
year-mon-day-hour-min-sec-tz doesn't change also. When we store time
in persistent store, it converts to year-mon-day-hour-min-sec-tz
presentation, and, if new program will have new tz database, it will
use new correct time_t value. We should only add check if system
support timezones, and automaticaly enable/disable it.
--
Pavel
valodzka
> I think Ruby should not include timezone database because
> its maintainance.
AFAIK, there are a plans to distribute ruby core libraries as a gems.
So, tz database can be packed as a gem, so it can be updated
immediately after new version.
> However it may be considerable to extend Time to hold arbitrary time
> offset from UTC, as DateTime:
This is partial solution, it doesn't solve main problem, but it is of
course better then current situation.
--
Pavel
Urabe Shyouhei
>> I think Ruby should not include timezone database because
>> its maintainance.
>
> AFAIK, there are a plans to distribute ruby core libraries as a gems.
> So, tz database can be packed as a gem, so it can be updated
> immediately after new version.
I bet you'll get tired of updating that database. There's a major difference
between "You can do" and "You actually do".
>> However it may be considerable to extend Time to hold arbitrary time
>> offset from UTC, as DateTime:
> This is partial solution, it doesn't solve main problem, but it is of
> course better then current situation.
What's that main problem?
valodzka
> between "You can do" and "You actually do".
ftp://elsie.nci.nih.gov/pub daily and updates gem if necessary and
configure cron to run it daily. That's all.
> What's that main problem?
get time in particular place, not with particular offset.
2) Time, except small range, remains unportable between different
platforms.
daz
>> I bet you'll get tired of updating that database. There's a major difference
>> between "You can do" and "You actually do".
>>
> If I solved this problem, I would write a script which checks server
> ftp://elsie.nci.nih.gov/pub daily and updates gem if necessary and
> configure cron to run it daily. That's all.
>
Here is a Ruby project which appears to use their 'zone.tab' file (?)
( data http://tzinfo.rubyforge.org/svn/tags/rel-0.0.1/data/zone.tab )
daz
Tanaka Akira
valodzka <valo...@gmail.com> writes:
> If I solved this problem, I would write a script which checks server
> ftp://elsie.nci.nih.gov/pub daily and updates gem if necessary and
> configure cron to run it daily. That's all.
I found a discussion in PHP.
http://thread.gmane.org/gmane.comp.php.devel/47609/focus=47681
I don't want to see similar discussion in Ruby.
--
Tanaka Akira
Urabe Shyouhei
>> I bet you'll get tired of updating that database. There's a major difference
>> between "You can do" and "You actually do".
> If I solved this problem, I would write a script which checks server
> ftp://elsie.nci.nih.gov/pub daily and updates gem if necessary and
> configure cron to run it daily. That's all.
No, that's not all. You then have to beg every single website on this planet
installing ruby to update your library, every time that script runs.
>> What's that main problem?
> 1) Offset in time is useless without tz database. Usually you want to
> get time in particular place, not with particular offset.
Your library cannot generate a time object representing
Sun, 01 Nov 2009 01:30:00 EDT
irb(main):001:0> require 'time2'
=> true
irb(main):002:0> TimeZone.local "America/New_York"
=> #<TimeZone: Japan>
irb(main):003:0> Time.local(2009, 11, 1, 1, 30, 0)
=> 2009-11-01 01:30:00 -0400
Isn't it incomplete to say you can "get time in particular place" because we
actually experience 1:30 in EDT? A time-with-offset strategy can handle this I
believe.
> 2) Time, except small range, remains unportable between different
> platforms.
That's unavoidable. Time is, or at least has an aspect of, an interface
between ruby and a platform.
PS: I cannot compile your library without modifications.
valodzka
> installing ruby to update your library, every time that script runs.
NetBSD, OpenBSD, DragonFly BSD, Mac OS X, most Linux distributions,
BeOS, AIX and more [http://en.wikipedia.org/wiki/Tz_database]) library
can be easy configured on compilation time or runtime to use system tz
database, and after that thats's problem of OS maintainers. This
covers, I think, about 99% of systems. For others, yes, you should
publish announcement, but this can be also handled in automated mode.
> Your library cannot generate a time object representing
> Sun, 01 Nov 2009 01:30:00 EDT
>
> irb(main):001:0> require 'time2'
> => true
> irb(main):002:0> TimeZone.local "America/New_York"
> => #<TimeZone: Japan>
> irb(main):003:0> Time.local(2009, 11, 1, 1, 30, 0)
> => 2009-11-01 01:30:00 -0400
>
> Isn't it incomplete to say you can "get time in particular place" because we
> actually experience 1:30 in EDT?
Unfortunately, I haven't understood your example. Why it can't handle?
>> TimeZone.local "America/New_York"
=> #<TimeZone: Europe/Minsk>
>> t = Time.local(2009, 11, 1, 1, 30, 0)
=> 2009-11-01 01:30:00 -0400
>> t.strftime "%a, %d %b %Y %H:%M:%S %Z"
=> "Sun, 01 Nov 2009 01:30:00 EDT"
>A time-with-offset strategy can handle this I believe.
Example. Two place, USA New York and Brazilia Manaus:
>> TimeZone.local "America/New_York"
=> #<TimeZone: America/Manaus>
>> t = Time.local(2009, 11, 1, 1, 30, 0)
=> 2009-11-01 01:30:00 -0400
>> t + 3600*24*30
=> 2009-12-01 00:30:00 -0500
>> TimeZone.local "America/Manaus"
=> #<TimeZone: America/New_York>
>> t = Time.local(2009, 11, 1, 1, 30, 0)
=> 2009-11-01 01:30:00 -0400
>> t + 3600*24*30
=> 2009-12-01 01:30:00 -0400
Can you see difference? The only way I see to handle this correctly -
time object should know that first place has DST and another - hasn't
> > 2) Time, except small range, remains unportable between different
> > platforms.
>
> That's unavoidable. Time is, or at least has an aspect of, an interface
> between ruby and a platform.
That's unavoidable only in two places - requiring current time and
current time zone. Everything else can be handled (and has handled) in
library.
> PS: I cannot compile your library without modifications.
I am interested in any information.
valodzka
>
> http://thread.gmane.org/gmane.comp.php.devel/47609/focus=47681
>
> I don't want to see similar discussion in Ruby.
solution.
Problem discussed in thread even in current implementation can be
handled by setting one variable ($__tz_path) from ruby.
--
Pavel
Urabe Shyouhei
>> No, that's not all. You then have to beg every single website on this planet
>> installing ruby to update your library, every time that script runs.
> On systems where tz database already installed (this is FreeBSD,
> NetBSD, OpenBSD, DragonFly BSD, Mac OS X, most Linux distributions,
> BeOS, AIX and more [http://en.wikipedia.org/wiki/Tz_database]) library
> can be easy configured on compilation time or runtime to use system tz
> database, and after that thats's problem of OS maintainers. This
> covers, I think, about 99% of systems. For others, yes, you should
> publish announcement, but this can be also handled in automated mode.
I think you'd better try that anyway. Tips: don't forget Windows.
>> Isn't it incomplete to say you can "get time in particular place" because we
>> actually experience 1:30 in EDT?
> Unfortunately, I haven't understood your example. Why it can't handle?
Soryy, I thought EDT was -0500. Then can you show me how to generate
Sun, 01 Nov 2009 01:30:00 EST ?
>>> 2) Time, except small range, remains unportable between different
>>> platforms.
>> That's unavoidable. Time is, or at least has an aspect of, an interface
>> between ruby and a platform.
> That's unavoidable only in two places - requiring current time and
> current time zone. Everything else can be handled (and has handled) in
> library.
Don't forget there are many methods that return Time objects: File.atime,
File.mtime, File.ctime, ...
valodzka
desktop, so regular updates of timezones database isn't realy
important.
> Soryy, I thought EDT was -0500. Then can you show me how to generate
> Sun, 01 Nov 2009 01:30:00 EST ?
>> TimeZone.local "America/New_York"
=> #<TimeZone: Europe/Athens>
>> Time.local(0, 30, 1, 1, 11, 2009, nil, nil, false, "America/New_York")
=> 2009-11-01 01:30:00 -0500
>> Time.local(0, 30, 1, 1, 11, 2009, nil, nil, true, "America/New_York")
=> 2009-11-01 01:30:00 -0400
These examples use current ruby Time API which, of course, can be
improved.
>>> >>> 2) Time, except small range, remains unportable between different
> >>> platforms.
> >> That's unavoidable. Time is, or at least has an aspect of, an interface
> >> between ruby and a platform.
> > That's unavoidable only in two places - requiring current time and
> > current time zone. Everything else can be handled (and has handled) in
> > library.
>
> Don't forget there are many methods that return Time objects: File.atime,
> File.mtime, File.ctime, ...
Sorry, I realy forget about this. But, anyway, these results can be
easy converted from and to internal presentation.
--
Pavel
Urabe Shyouhei
>> Soryy, I thought EDT was -0500. Then can you show me how to generate
>> Sun, 01 Nov 2009 01:30:00 EST ?
>
>>> TimeZone.local "America/New_York"
> => #<TimeZone: Europe/Athens>
>>> Time.local(0, 30, 1, 1, 11, 2009, nil, nil, false, "America/New_York")
> => 2009-11-01 01:30:00 -0500
>>> Time.local(0, 30, 1, 1, 11, 2009, nil, nil, true, "America/New_York")
> => 2009-11-01 01:30:00 -0400
> These examples use current ruby Time API which, of course, can be
> improved.
I see. You definitely need a better API though.
>>>>>>> 2) Time, except small range, remains unportable between different
>>>>> platforms.
>>>> That's unavoidable. Time is, or at least has an aspect of, an interface
>>>> between ruby and a platform.
>>> That's unavoidable only in two places - requiring current time and
>>> current time zone. Everything else can be handled (and has handled) in
>>> library.
>> Don't forget there are many methods that return Time objects: File.atime,
>> File.mtime, File.ctime, ...
> Sorry, I realy forget about this. But, anyway, these results can be
> easy converted from and to internal presentation.
I think this point (2) does not involve with zoneinfo vs. offset discussion.
Tanaka Akira
valodzka <valo...@gmail.com> writes:
> Problem discussed in thread even in current implementation can be
> handled by setting one variable ($__tz_path) from ruby.
It solves the maintainance problem. Good.
However, it needs a configuration for $__tz_path.
No configuration is much better.
I don't think all Ruby user configure it.
Also, if time2 supports out of time_t, the timezone db in OS
is not useful. So you may wish time2 installs it's own
timezone db. But it causes the maintainance problem again.
It seems you have a plan for that.
There is no such problem if we store a time offset (not
timezone) in Time object, even if we extend Time to support
out of time_t.
I found marshal forget the timezone in time2:
% ../bin/ruby -Ilib -rtime2 -e '
p TimeZone.local
t = Time.local(2000).localtime(TimeZone["US/Pacific"])
p t
p Marshal.load(Marshal.dump(t))
'
#<TimeZone: Japan>
1999-12-31 07:00:00 -0800
2000-01-01 00:00:00 +0900
It seems time2's Marshal.load uses the local time.
Basically, marshal preserves the object.
So someone may request to preserve the timezone by marshal.
But it is a difficult problem.
If timezone name is marshaled with the time, the timezone
may not exist at Marshal.load because timezone database is
OS dependent. (using $__tz_path is assumed.)
For example, some OS (GNU/Linux) provieds "Japan"
timezone but some other OS (FreeBSD) don't provide it.
If timezone data itself is marshaled, it may be obsoleted
between Marshal.dump and Marshal.load due to DST rule change
and leap second determination. It is possible if the
marshaled data is stored in a file/DB. It is difficult to
update the marshaled timezones in a file/DB.
There is no such problem if we store a time offset (not
timezone) in Time object because a time offset is easily
marshalled as a number and it will not be obsoleted.
As the previous example, time2 find "Japan" timezone as
#<TimeZone: Japan> in my environment. This is interesting
because it is difficult to know the current timezone name.
It seems that time2 scans the timezone directory. It needs
many open system call. It makes Ruby slow.
% time ../bin/ruby -Ilib -rtime2 -e 'Time.now'
../bin/ruby -Ilib -rtime2 -e 'Time.now' 0.14s user 0.06s system 99% cpu 0.202 total
% time ../bin/ruby -Ilib -rtime2 -e 'Time.now'
../bin/ruby -Ilib -rtime2 -e 'Time.now' 0.14s user 0.06s system 98% cpu 0.199 total
% time ../bin/ruby -Ilib -rtime2 -e 'Time.now'
../bin/ruby -Ilib -rtime2 -e 'Time.now' 0.13s user 0.06s system 98% cpu 0.199 total
% time ruby -e 'Time.now'
ruby -e 'Time.now' 0.02s user 0.00s system 95% cpu 0.021 total
% time ruby -e 'Time.now'
ruby -e 'Time.now' 0.02s user 0.00s system 91% cpu 0.022 total
% time ruby -e 'Time.now'
ruby -e 'Time.now' 0.02s user 0.00s system 94% cpu 0.021 total
time2 has ~0.18 sec overhead.
Also, even if a timezone is found, it is possible that it is
not exactly same as the system timezone. For example, time2
can't use the system timezone directly on a OS which don't
use Olson time zone database. If the timezone with time2 is
different from the system timezone, Ruby behaves
inconsistently to all other programs (except PHP and
PostgreSQL?) on the OS.
There is no such problem if we store a time offset (not
timezone) in Time object because it doesn't need timezones
other than the system timezone.
I think multiple timezone support should be separated as
external library.
I guess it will be used to personalize a date in web
applications. If so, timezone library can be used at
constructing a web page. I don't see a necessity that Time
object refer a timezone.
--
Tanaka Akira
valodzka
>
> However, it needs a configuration for $__tz_path.
> No configuration is much better.
>
> I don't think all Ruby user configure it.
> Also, if time2 supports out of time_t, the timezone db in OS
> is not useful.
Olson tz database uses 64 bit representation independently from time_t
size.
> So you may wish time2 installs it's own
> timezone db. But it causes the maintainance problem again.
> It seems you have a plan for that.
Unfortunatly I haven't, and this is the biggest problem.
This can be solved by marshaling both, time zone name and offset. If
we have problem with time zone name - we can use offset.
>
> As the previous example, time2 find "Japan" timezone as
> #<TimeZone: Japan> in my environment. This is interesting
> because it is difficult to know the current timezone name.
>
> It seems that time2 scans the timezone directory. It needs
> many open system call. It makes Ruby slow.
>
> % time ../bin/ruby -Ilib -rtime2 -e 'Time.now'
> ../bin/ruby -Ilib -rtime2 -e 'Time.now' 0.14s user 0.06s system 99% cpu 0.202 total
> % time ../bin/ruby -Ilib -rtime2 -e 'Time.now'
> ../bin/ruby -Ilib -rtime2 -e 'Time.now' 0.14s user 0.06s system 98% cpu 0.199 total
> % time ../bin/ruby -Ilib -rtime2 -e 'Time.now'
> ../bin/ruby -Ilib -rtime2 -e 'Time.now' 0.13s user 0.06s system 98% cpu 0.199 total
>
> % time ruby -e 'Time.now'
> ruby -e 'Time.now' 0.02s user 0.00s system 95% cpu 0.021 total
> % time ruby -e 'Time.now'
> ruby -e 'Time.now' 0.02s user 0.00s system 91% cpu 0.022 total
> % time ruby -e 'Time.now'
> ruby -e 'Time.now' 0.02s user 0.00s system 94% cpu 0.021 total
>
> time2 has ~0.18 sec overhead.
I doubt if 0.18 second per process is a big problem. And this can be
avoided by setting TZ enviroment variable.
> Also, even if a timezone is found, it is possible that it is
> not exactly same as the system timezone. For example, time2
> can't use the system timezone directly on a OS which don't
> use Olson time zone database. If the timezone with time2 is
> different from the system timezone, Ruby behaves
> inconsistently to all other programs (except PHP and
> PostgreSQL?) on the OS.
I can imagine it, but it will be possible only with exotic systems.
> There is no such problem if we store a time offset (not
> timezone) in Time object because it doesn't need timezones
> other than the system timezone.
>
> I think multiple timezone support should be separated as
> external library.
>
> I guess it will be used to personalize a date in web
> applications. If so, timezone library can be used at
> constructing a web page. I don't see a necessity that Time
> object refer a timezone.
There are one main problem with offset: it isn't fixed for fixed place
(example with new york and manaus here
http://groups.google.com/group/ruby-core-google/msg/f00c55f56482fc73),
and I don't known how to solve it.
Tanaka Akira
valodzka <valo...@gmail.com> writes:
> This can be autoconfigured of course.
Good.
> Olson tz database uses 64 bit representation independently from time_t
> size.
My Debian Etch (i386) system uses TZif format (not TZif2 format).
% strings -a /usr/share/zoneinfo/Asia/Tokyo|head -1
TZif
Is this file 64 bit representation?
> Unfortunatly I haven't, and this is the biggest problem.
I wrote a patch:
http://www.a-k-r.org/tmp/ruby-big-time.patch
> This can be solved by marshaling both, time zone name and offset. If
> we have problem with time zone name - we can use offset.
But time zone name may not be preserved on marshal.
Marshal.load may ignore it if the system has no
corresponding timezone. So, programmers shouldn't depend on
that.
Don't add a feature which should not be used.
> I doubt if 0.18 second per process is a big problem. And this can be
> avoided by setting TZ enviroment variable.
Not so big but bit frustrated.
Ruby is used for one liner which is very short program.
0.18 second may be major factor of such program.
For TZ, no configuration is much better.
> I can imagine it, but it will be possible only with exotic systems.
If I remember correctly, Windows and HP-UX doesn't use Olson
timezone database.
I guess they have a timezone which is not included in the
database. I'm not sure, though.
> There are one main problem with offset: it isn't fixed for fixed place
> (example with new york and manaus here
> http://groups.google.com/group/ruby-core-google/msg/f00c55f56482fc73),
> and I don't known how to solve it.
Yes. This is what I said at the last sentence of
[ruby-core:22949].
But why you add a timezone at first place?
Assume a web based messaging system.
Each user has timezone preference.
User A sends a message to user B and C.
User B see the date of the message in the timezone of B.
User C see the date of the message in the timezone of C.
In this scenario, timezone should be used at constructing
the page for B and C.
The timezone of A is not used. No need to store the
timezone of A in a Time object.
It is enough to set a timezone at the last place.
After the last place, Time object is used just for
formatted and embedded for a presentation form.
I.e. time calculations (Time#+, etc.) are not used after the
timezone is set. So time offset is enough for this purpose.
--
Tanaka Akira
valodzka
> > size.
>
> My Debian Etch (i386) system uses TZif format (not TZif2 format).
>
> % strings -a /usr/share/zoneinfo/Asia/Tokyo|head -1
> TZif
>
> Is this file 64 bit representation?
Nope. Debian is really stable system.
> > Unfortunatly I haven't, and this is the biggest problem.
>
> I wrote a patch:http://www.a-k-r.org/tmp/ruby-big-time.patch
>
> Yes. This is what I said at the last sentence of
> [ruby-core:22949].
> But why you add a timezone at first place?
>
> Assume a web based messaging system.
> Each user has timezone preference.
>
> User A sends a message to user B and C.
> User B see the date of the message in the timezone of B.
> User C see the date of the message in the timezone of C.
>
> In this scenario, timezone should be used at constructing
> the page for B and C.
>
> The timezone of A is not used. No need to store the
> timezone of A in a Time object.
>
> It is enough to set a timezone at the last place.
> After the last place, Time object is used just for
> formatted and embedded for a presentation form.
> I.e. time calculations (Time#+, etc.) are not used after the
> timezone is set. So time offset is enough for this purpose.
Okay, may be you are right. But I haven't understood purpose of your
patch. Can you give an example of problem which has been solved by it?
--
Pavel
"Martin J. Dürst"
time sooner or later, so it might be a good idea to work on
timezone-related problems in core Ruby soon.
Updates of timezone information doesn't have to be frequent,
for most purposes (work in a locality that doesn't change
timezone rules), even no update is okay. To keep current
for timezones world-wide, an update about once a month
should be more than enough; governments change timezone rules
at their will, but do it well in advance.
In general, it is difficult if not impossible to provide a
time class that satisfies everybody from business people
to astronomers and historians (and is still easy to use
by programmers). But we should be open to improvements.
Regards, Martin.
daz
>
> Here is a Ruby project which appears to use their 'zone.tab' file (?)
>
>
> http://tzinfo.rubyforge.org/
>
> ( data http://tzinfo.rubyforge.org/svn/tags/rel-0.0.1/data/zone.tab )
>
>
> daz
>
>
Sorry, you knew that already ;)
Here's my second (possibly also useless) contribution to this thread.
I noticed the Python distro carries TCL/TK and, while looking for
something else, found its tzdata directory[1].
I looked in TCL repository and found this maintenance tool for
updating their internal data.
http://tcl.cvs.sourceforge.net/viewvc/tcl/tcl/tools/tclZIC.tcl?revision=1.2.2.6&view=markup
It looks tidy, so I'm posting for the TCL fans, on here.
daz
[1] http://tcl.cvs.sourceforge.net/viewvc/tcl/tcl/library/tzdata/
Tanaka Akira
valodzka <valo...@gmail.com> writes:
My patch just change internal representation to relax the
representable range.
With the patch:
% ./ruby -e 'p Time.utc(2**100)'
1267650600228229401496703205376-01-01 00:00:00 UTC
Without the patch:
% ruby -e 'p Time.utc(2**100)'
-e:1:in `utc': bignum too big to convert into `long' (RangeError)
from -e:1:in `<main>'
No timezone/offset related extension yet.
I think Time.mktime should take optional 8th argument,
offset, as
Time.mktime(year, mon, mday, hour, min, sec, usec, offset).
offset can be a number or a string such as "+09:00".
:std and :dst may also be accepted for tm_isdst for
mktime().
If people needs timezone abbreviations really, 9th argument
may be extended. It is just for Time#zone, etc. Not used
for time calicurations.
--
Tanaka Akira
Tanaka Akira
"Martin J. Dürst" <due...@it.aoyama.ac.jp> writes:
> I agree with Pavel. Japan also may be adapting daylight savings
> time sooner or later, so it might be a good idea to work on
> timezone-related problems in core Ruby soon.
>
> Updates of timezone information doesn't have to be frequent,
> for most purposes (work in a locality that doesn't change
> timezone rules), even no update is okay. To keep current
> for timezones world-wide, an update about once a month
> should be more than enough; governments change timezone rules
> at their will, but do it well in advance.
If you consider only a local timezone, current Ruby works
well if you update the timezone database in your OS.
--
Tanaka Akira