[tz] DST ends 2040 in Oracle database

[Joachim Damm]

Hi,

only for clarifying.
Our software is for the pharmaceutical industry and there it is not acceptable if the expiry date of an active ingredient  is calculated wrongly. The FDA (US Food and Drug Administration) will also no accept wrong timestamps in the production, also not in the distant future. 
>From the Oracle support I got the information that they are internally checking with their DST experts.
The former information from Oracle was, that this is a known issue which will be fix in future with below enhancement request raised.


Kind Regards

i.A. Joachim Damm

Senior Database Consultant Systems Integration




Werum IT Solutions GmbH
Wulf-Werum-Str. 3, 21337 Lüneburg, Germany

T +49 4131 8900-515
F +49 4131 8900-20
Joachim.Damm at Werum.com
www.werum.com

Geschäftsführer / Managing Directors: Rüdiger Schlierenkämper, Richard Nagorny, Hans-Peter Subel
RG Lüneburg / Court of Jurisdiction: Lüneburg, Germany
Handelsregisternummer / Commercial Register: HRB 204984
USt.-IdNr. / VAT No.: DE 116 083 850

Connect with us:




-----Original Message-----
From: Robert Elz [mailto:kre at munnari.OZ.AU] 
Sent: Dienstag, 29. Januar 2019 07:43
To: Phake Nick <c933103 at gmail.com>
Cc: Sergiusz Wolicki <sergiusz at wolicki.com>; Time zone mailing list <tz at iana.org>; Joachim Damm <Joachim.Damm at werum.com>
Subject: Re: [tz] DST ends 2040 in Oracle database

    Date:        Tue, 29 Jan 2019 12:13:47 +0800
    From:        Phake Nick <c933103 at gmail.com>
    Message-ID:  <CAGHjPPL=8HkNyvdHAqJRAd48Dso37n11sx_5DP1Aygxs70A7Rg at mail.gmail.com>


  | Except it is already year 2019 and 2038 January 19 is now only less than 19
  | years into the future. If one get a 20-year mortgage now, the final payment
  | day/time will already be after 2038. It's probably about time for
  | developers and vendors to consider the problem more seriously.

Perhaps, but if you haven't already done so, you need to read Paul's message...

The developers who need to take this kind of issue seriously are the ones (to use your example) who are recoding the mortgage end date/time.

If your mortgage were in New York (probably a huge one, and 20 years might not be enough...) then the end date time of that 20 year mortgage should be recorded as "5:00 p.m. on the January 29, 2039, in New York City".

If your mortgage is in Hong Kong (might need to be even longer than for New York!) the end date time should be recorded as "17:00 on 29th of January, 2039, in Hong Kong".

In each case the place might need to be more specific (that is the final payment might need to be in a specific room in a specific building or something, fo facilitate the document echange, or perhaps "at a location to be agreed", but that isn't relevant to this discussion.)

Under no circumstances (other than specific agreement by the parties) should it be recorded as "2039-01-29 21:00:00 UTC" or
"2030-01-29 09:00:00 UTC" (if I did the conversions in my head
correctly) - that would always be wrong (again unless that's what was specifically agreed - the person/software recording the end time should *never* make that kind of change "just because UTC is always better".

kre