I've read I can add timezone information on an ISO8601 date by appending for example Z or +02 or -03:00.
I've also read that I can add timespan information by appending a P and then the time, for example 4DT2H (4 days and two hours).
How can I combine the two? Timezone or timespan first?
E.g. 2018-10-18T14:20+02P1D vs 2018-10-18T14:20P1D+02
By having two values, you are basically describing when an event starts, and how long it lasts. Such values are covered in section 4.4.4.3 of the ISO 8601 specification, titled "Representations of time interval identified by start and duration".
The spec requires full compliance with the established formats for both the timestamp and the time period parts, separating them with a forward slash (/) character.
For example: 2018-10-18T14:20+02/P1D
The time zone offset (whether Z, or +02, or -03:00) belongs with the timestamp, before the slash.
That said, I know of few parsers that understand this format. It is compliant, but not every parser of ISO 8601 necessarily understands every part of the spec.
Related
I am trying to parse an ISO 8601 timestamp which looks like this: "20220603T054813Z". My supervisor gave me this timestamp asking me to parse it (she found it on wiki under the ISO-8601 page) but I couldnt find information regarding this type of timestamp anywhere else.
I am trying to parse it using a LocalDateTime instance and using a pre-defined format but I cant find any. Using any of the classes doesnt work neither do the pre-defined formatters for ISO 8601 timestamps. There's no example in the documentation that explains how to handle this particular case and that makes me wonder if this is a valid ISO 8601 case. It does work with my own created format but I am writing a logic to handle ISO 8601 cases without me having to define a custom format, as much as possible. atleast for the ISO 8601 timestamps. Is this a valid ISO 8601 timestamp even? Because usually they have separators for date and time.
Is there a way to handle timestamps like these, which doesnt have any separators or whitespaces, with a pre-defined formatter? Maybe i am missing something. Any help would be appreciated, thanks!
Given rails has a convention for most common tasks, is there a format of date/time data that ruby/rails ingests most easily, or which it 'prefers'?
I will have date/time data coming from an external source, and I can choose how it's formatted (but it not be easy to change later). I have researched and found two recommended formats:
A string of format YYYY-MM-DD HH:MM:SS
Unix epoch time (i.e. number of seconds since 1 Jan 1970)
Does rails deal more easily with one of these formats over the other (or is there another convention?)
Additional note: I can see from this talk that it's almost always best to store time in UTC, so I have that much figured out
I would agree that Ruby on Rails default to using the UTC time zone at least in the database.
I do not see a strong convention what time string format Rails prefers, but I would always choose ISO 8601: 'YYYY-MM-DDTHH:MM:SSZ'
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.
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.
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.
What is the correct format to be used for Edm.Time ?
I see in the protocol document the format for DateTime and DateTimeOffset as follows:
Datetime : "yyyy-MM-dd'T'HH:mm:ss.fff"
DateTimeoffset : "yyyy-MM-dd'T'HH:mm:ss.fffZ"
I did check the protocol here : http://www.w3.org/TR/xmlschema-2/ but could not get the formatting to be used for Edm.Time.
Currently we are using XmlConvert.ToString to convert the time span value to a string representation.
Is there any specific representation that OData recommends for Timespan ?
The formats should be reasonably well documented here, which points you to this link (in the case of Edm.Time).
From XML Schema 2:
3.2.8.1 Lexical representation
The lexical representation for time is the left truncated lexical
representation for dateTime: hh:mm:ss.sss with optional following time
zone indicator. For example, to indicate 1:20 pm for Eastern Standard
Time which is 5 hours behind Coordinated Universal Time (UTC), one
would write: 13:20:00-05:00. See also ISO 8601 Date and Time Formats
(§D).
Note that time-and-date-land have had their issues over the years. The date format varies based upon payload format and version. For instance, JSON Verbose used the /Date(...)/ format for OData v2, but changed to ISO 8601 in OData v3 (much to the collective relief of anyone who doesn't have to implement an OData server and care about all these nuances). This is similar to the struggles that the ASP.NET stack has gone through: http://www.hanselman.com/blog/OnTheNightmareThatIsJSONDatesPlusJSONNETAndASPNETWebAPI.aspx.
I am looking at the <xforms:input> formatting documentation and am curious if it is at all possible to display the date as "3 Jul 2011". This should formatting very simple given the use of Java's SimpleDateFormat with the mask [d] [MMM] [yyyy]. The <xforms:input> documentation makes it seem possible to change the canonical format but only references Regex expressions.
Or am I restricted to the masks [M], [D] and [Y]?
You can choose pretty much any format you want when displaying a date or time with <xforms:output>. However, when capturing a date or time with <xforms:input>, Orbeon Forms limits you to just a few formats, as documented.
The reason for this is somewhat technical: for inputs, Orbeon Forms needs to be able to both format the date/time in the format you specify, and to parse it. And the parsing is implemented to accept as many reasonable date or time formats entered by the user. For instance, if you choose a [M]/[D]/[Y] format (typical in the US), you can enter 12/2/2011, but also 12/2 (skipping the year), or even 2 (skipping both the year and the month), or today, as well as several other formats.
The bottom line is that because of this "smart parsing", the <xforms:input> can only support a number of predefined formats. Additional formats can be added, but this requires Orbeon Forms itself to be changed to support those additional formats.