KEP2: Modification of datetime type, introduction of 'tz' sub-tag

[Hendrik Helwich]

Hi Georg,

Am Montag, 20. Dezember 2010 19:19:12 schrieb Georg C. F. Greve:
> Hi Hendrik,
>
> On Monday 20 December 2010 15.17:59 Hendrik Helwich wrote:
> > as i understand time zones, the DST is a part of it.
> > So e.g. if you are in germany (where DST is used) and you want a event
> > start in the summer at 9 o clock it would have the start time of 7 o
> > clock in UTC (DST offset +2). With KEP 2 it would be stored as 8 o clock
> > UTC time because the standard offset would be used instead of the
> > currently active DST offset. So this would be wrong because the event
> > would happen at 7 o clock UTC time and not at 8 o clock UTC time.
>
> You're right of course, which is why the calculation metric to arrive at
> the correct time given in KEP 2 resolves this issue again. But the true
> point you've made, which I only realized later, is that it screws the
> datetime stamps.
>
> > Everything is fine till now. Somebody now decides to to switch the names
> > of DST and standard time in germany (I know this is not very realistic
> > :-)
>
> In the array of realistic scenarios, this one is somewhere alongside "a
> giant meteor is going to wipe out Germany, speeding up continental drift to
> displace Rome, which now has a new time zone", I dare say. ;)

After a short google i found this article:
http://www.worldtimezone.com/dst_news/dst_news_turkey02.html
This shows that a scenario of a change of the standard timezone offset is not 
as unrealistic as you wrote. 
In fact it could even happen next year that Turkey changes the standard time 
zone offset by 30 minutes.

> > I meant to store a local time in the UTC formatting of RFC3339.
>
> Yes. I understood that.
>
> But that format is not UTC formatting, it is RFC3339 formatting of UTC, so
> what you're proposing is to create a new, incompatible and easily confused
> format that looks like RFC3339, but isn't, and gives local times, but many
> parsers may mistakenly read it as UTC, because that is what it looks like.

Its the same with the proposed UTC/local mixed time. This is also no correct 
UTC time.
And this is also why i voted for storing local times directly

> So I think that's a recipe for desaster.

Yes i think so too. But its the same for what is proposed in KEP 2.
So local times might be the better solution.

> > This is not true i think. If you want the event to happen in a local time
> > (which is probably the default usecase) you only have to convert it back
> > if the time is stored in UTC. If it is stored directly in local time you
> > need no calculation and have therefore less complexity and a better
> > readability.
>
> Actually I think there is a case for storing local time, but this is not
> it.
>
> > Why should RFC3339 be used for local times if it is not designed for it?
> > This makes no sense in my opinion.
>
> I agree. Which is why I didn't agree with your proposal to do so. ;)

No, i proposed to somehow store local times directly.
if you already want to store UTC/local mixed times in the UTC format of 
RFC3339 and don't want to use another library, i said it would be better to 
directly store local times in the UTC format. Both solutions would store 
wrong UTC times but  technically solution 2 would be better because you do 
not need to convert to the local time with a faulty algorithm. But i agree 
that both solutions are very bad.

> The whole thing is really like trying to fit a curve to a straight line,
> when you fix one point, the other half now stands off... let me try to
> approach this from a new angle. Maybe it'll help us clear our minds and get
> others in on resolving this, as well.

You are right, Good Idea :-)

Best regards,
Hendrik

> I'll start this into a fresh thread...
>
> Best regards,
> Georg