<commit_before>RFC 0036: Add timezone offset to date object
========================================================================
$Id$

@authors: hinckel, kiesel
@created: Thu Aug 25 13:22:10 CEST 2005
@status: draft
@category: <core>

Scope of Change
---------------
Add the timezone offset against GMT to the util.Date class.

Rationale
---------
This is required to be able to calculate the GMT representation 
from a given date object. This information is required to properly
calculate time differences between date objects in different time-
zones.

Functionality
-------------
A new member $tz will be added to the util.Date class that contains
the offset of the timezone of the date object against GMT in seconds.
Negative offsets indicate timezones west of GMT, positive ones indicate
timezones east of GMT.

If constructing a date object without explicitely defining a timezone,
the hosts default timezone will be used.

Security considerations
-----------------------
n/a

Speed impact
------------
This change adds a member variable and various getters and setters to the
util.Date class, which is a core class. This change will decrease speed and
increase the classes memory footprint. Speed deterioration should not be
measureable; the additional memory required is an acceptable trade-off.

Dependencies
------------
n/a

Related documents
-----------------
- Patch against svn trunk (TBI)
  n/a

Comments
--------
- kiesel, Thu Aug 25 13:31:50 CEST 2005
  rdbms systems like Sybase ASE and MySQL (and probably others) do not store
  any timezone information with their date types. This is usually handled by
  assigning the database a timezone which is then known to all systems accessing
  that database.
  To be able to correctly extract a date column from a database, we might need
  to supply this information to the rdbms.DBConnection-derived classes. This
  could happen by extending the DSN format and add a new parameter. Example:
  "sybase://wurst:brot@SERVER/database?autoconnect=1&defaulttz=CET

- kiesel, Thu Aug 25 13:34:30 CEST 2005
  LDAP servers do store timezone information, the peer.ldap package thus is
  only slightly affected by this change.

- kiesel, Thu Aug 25 13:59:56 CEST 2005
  Should util.TimeZone become part of <core>?

- george, Thu Aug 25, 13:00 GMT 2005
  I think it would speare the server the burden of knowing where it is -- also
  would make the database geographically portable -- to store all times in GMT
  on the server and additionally store TimeZone, maybe like "CEST", "EEST",
  "GMT", etc.
  Then, the util.Date object can get himself in GMT form and restore the time
  whatever timezone is asked of him. I think util.Date should be able to reproduce 
  times in different timezones, thus carry such a parameter...

  Also, an important factor to this is DST. DST (Daylight Saving Time) is a 
  mechanism which offsets by a certain amount of time (1 hour mostly, but there 
  are cases where this time is just 30 mins or even more situations) the time 
  in a certain region. This mechanism is not the same around the world, and it 
  is in no way syncronised with GMT.

  So an answer to this might be to store, the TimeZone and the actual offset 
  relative to GMT that existed at the time de date was inserted. (19:00 CEST is
  GMT + 1 or GMT + 2, so we just say 19:00 CEST (+2), and this way we know 
  exactly the timezone and the actual offset relative to GMT.)

- kiesel, Fri Aug 26 14:27:20 CEST 2005
  The database stuff will be decided upon in another rfc, since the whole issue
  is affected by this, but does not belong into this rfc.

- kiesel, Fri Aug 26 14:27:20 CEST 2005
  It seems not to be sufficient to store the GMT offset with in a date object, because
  when adding - say - half a year to a certain date for a timezone has uses DST,
  the timezone itself must change.
  By looking at the timezone offset, you cannot tell whether to move the timezone
  for DST or not (fe. +0100 can be CET =`Central European time` - winter -  or 
  BST `British Summer Time` - summer).

<EOF><commit_msg>- added comment to not use short timezone names, instead we should use the   long versions (e.g. "Europe/Berlin")<commit_after>RFC 0036: Add timezone offset to date object
========================================================================
$Id$

@authors: hinckel, kiesel
@created: Thu Aug 25 13:22:10 CEST 2005
@status: draft
@category: <core>

Scope of Change
---------------
Add the timezone offset against GMT to the util.Date class.

Rationale
---------
This is required to be able to calculate the GMT representation 
from a given date object. This information is required to properly
calculate time differences between date objects in different time-
zones.

Functionality
-------------
A new member $tz will be added to the util.Date class that contains
the offset of the timezone of the date object against GMT in seconds.
Negative offsets indicate timezones west of GMT, positive ones indicate
timezones east of GMT.

If constructing a date object without explicitely defining a timezone,
the hosts default timezone will be used.

Security considerations
-----------------------
n/a

Speed impact
------------
This change adds a member variable and various getters and setters to the
util.Date class, which is a core class. This change will decrease speed and
increase the classes memory footprint. Speed deterioration should not be
measureable; the additional memory required is an acceptable trade-off.

Dependencies
------------
n/a

Related documents
-----------------
- Patch against svn trunk (TBI)
  n/a

Comments
--------
- kiesel, Thu Aug 25 13:31:50 CEST 2005
  rdbms systems like Sybase ASE and MySQL (and probably others) do not store
  any timezone information with their date types. This is usually handled by
  assigning the database a timezone which is then known to all systems accessing
  that database.
  To be able to correctly extract a date column from a database, we might need
  to supply this information to the rdbms.DBConnection-derived classes. This
  could happen by extending the DSN format and add a new parameter. Example:
  "sybase://wurst:brot@SERVER/database?autoconnect=1&defaulttz=CET

- kiesel, Thu Aug 25 13:34:30 CEST 2005
  LDAP servers do store timezone information, the peer.ldap package thus is
  only slightly affected by this change.

- kiesel, Thu Aug 25 13:59:56 CEST 2005
  Should util.TimeZone become part of <core>?

- george, Thu Aug 25, 13:00 GMT 2005
  I think it would speare the server the burden of knowing where it is -- also
  would make the database geographically portable -- to store all times in GMT
  on the server and additionally store TimeZone, maybe like "CEST", "EEST",
  "GMT", etc.
  Then, the util.Date object can get himself in GMT form and restore the time
  whatever timezone is asked of him. I think util.Date should be able to reproduce 
  times in different timezones, thus carry such a parameter...

  Also, an important factor to this is DST. DST (Daylight Saving Time) is a 
  mechanism which offsets by a certain amount of time (1 hour mostly, but there 
  are cases where this time is just 30 mins or even more situations) the time 
  in a certain region. This mechanism is not the same around the world, and it 
  is in no way syncronised with GMT.

  So an answer to this might be to store, the TimeZone and the actual offset 
  relative to GMT that existed at the time de date was inserted. (19:00 CEST is
  GMT + 1 or GMT + 2, so we just say 19:00 CEST (+2), and this way we know 
  exactly the timezone and the actual offset relative to GMT.)

- kiesel, Fri Aug 26 14:27:20 CEST 2005
  The database stuff will be decided upon in another rfc, since the whole issue
  is affected by this, but does not belong into this rfc.

- kiesel, Fri Aug 26 14:27:20 CEST 2005
  It seems not to be sufficient to store the GMT offset with in a date object, because
  when adding - say - half a year to a certain date for a timezone has uses DST,
  the timezone itself must change.
  By looking at the timezone offset, you cannot tell whether to move the timezone
  for DST or not (fe. +0100 can be CET =`Central European time` - winter -  or 
  BST `British Summer Time` - summer).

- hinckel, Mon Sep  5 08:53:55 CEST 2005
  When specifying a timezone we should not use the short names (e.g. CET,
  BST) because some are used for different timezones. When specifying a
  timezone we should always use the long names (e.g. "Europe/Berlin",
  "America/Los_Angeles").
  See: http://java.sun.com/j2se/1.5.0/docs/api/java/util/TimeZone.html

<EOF>
{'fraction_non_alphanumeric': 0.08632508423376321, 'fraction_numerical': 0.02614151272220286, 'mean_word_length': 3.423432682425488, 'pattern_counts': {'":': 0, '<': 9, '<?xml version=': 0, '>': 9, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2799356', 'n_tokens_mistral': 2573, 'n_tokens_neox': 2295, 'n_words': 1316}