CODEWITHSUNDEEP
timezonedst
Stroboskop
Stroboskop

Reputation: 4356

Best way to present the ambiguous extra hour when winter time begins

What is the standard way to present the ambiguous extra hour when winter time begins?

So far i used localized time formats to display and parse dates and times. E.g. 1. January 2014, 15:27.

I'm using location based time zones like "Europe/Berlin". And i can't just change to plain GMT offsets because i do need to perform calculations on the dates. Otherwise i would get the wrong absolute time when moving across DST change dates.

All this works fine except for the one hour at the end of DST (e.g. October 26th 2014, 2am-3am) which occurs twice. I need to present it in a way that i can later parse again.

Is there a stadardized format? Do i just add a custom symbol? Do i use the GMT offset additionally to the geographic time zone? And how do i know when to use this special format - because i don't want to print it all the time, since it's redundant most of the year.

Upvotes: 3

Views: 192

Answers (2)

Matt Johnson-Pint
Matt Johnson-Pint

Reputation: 241808

There isn't a standard that combines everything. The closest you can get is with two fields. One which would be an ISO8601/RFC3339 Date+Time+Offset, and another which would be the IANA/Olson time zone.

Depending on your platform, you may have a single object that represents both, such as a DateTime in Joda-Time or a ZonedDateTime in Noda Time. But there is no standardized representation of this as a string.

Here are some that I have seen though:

  • Two completely separate strings:

    "2014-10-26T02:00:00+01:00"
"Europe/Berlin"

  • One concatenated string, space separated:

    "2014-10-26T02:00:00+01:00 Europe/Berlin"

  • One concatenated string with a space and using parentheses:

    "2014-10-26T02:00:00+01:00 (Europe/Berlin)"

  • One concatenated string without any space, but with square brackets: (thanks Basil)

    "2014-10-26T02:00:00+01:00[Europe/Berlin]"

  • As JSON, with some predetermined field names:

    {
    value: "2014-10-26T02:00:00+01:00",
    zone: "Europe/Berlin"
}

  • As XML, with some predetermined attribute names:

    <TimeStamp Value="2014-10-26T02:00:00+01:00" Zone="Europe/Berlin" />

  • As XML, with some predetermined element names:

    <TimeStamp>
    <Value>2014-10-26T02:00:00+01:00</Value>
    <Zone>Europe/Berlin</Zone/>
</TimeStamp>

Any of these would be acceptable. Pick the one that fits your situation, or adapt to something similar.

Regarding your question:

... how do i know when to use this special format ...

When you're recording an event that has already passed and cannot be changed, then you do not need to store the time zone. The date+time+offset value alone is sufficient. Otherwise, you need both.

Upvotes: 2

Basil Bourque
Basil Bourque

Reputation: 339858

The answer by Matt Johnson is correct and insightful.

Java 8 & java.time.*

Let me add another to his list, from the new java.time.* classes bundled with Java 8 and defined by JSR 310. These new classes are inspired by Joda-Time but are re-architected.

The default used by java.time.ZonedDateTime is one concatenated string using square brackets around the time zone name and no spaces.

2014-10-26T13:49:48.278+01:00[Europe/Berlin]

@MattJohnson Feel free to merge this answer's content with yours if you wish.

Upvotes: 2

Related Questions