I can't find it specified anywhere. I did find a Microsoft example that had "5/5/1955". Is that d/m/y or y/m/d.
I'm guessing that I probably ought to use ISO 8601, but it would be nice to know for sure.
According to the OASIS spec, the type associated with URI
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/dateofbirth is xs:date, so it should be a normal XML date format... which is indeed ISO-8601, according to XML Schema Part 2. (That talks about the time zone for a date being representable, which strikes me as a little odd, but never mind.)
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!
I'd like to make a parser for DNS records (e.g. what gets returned by dig), but I can't find a standard textual representation - as far as I can tell the RFCs just specify the wire format. However, the intro in https://tools.ietf.org/id/draft-daley-dnsxml-00.html implies that there is a standard format:
Historically, DNS Resource Records (RRs) have a presentation format and wire format. The presentation format is typically used to conveniently store DNS RRs in Human Readable Form.
Does anyone know if these presentation formats are defined anywhere?
The "zone file" format is standardized is standardized in section 5 of RFC1035
This is the standard text representation.
But about
I'd like to make a parser for DNS records (e.g. what gets returned by dig)
Do not make a parser on dig output. Use any kind of programming language you want, you will find libraries doing DNS requests and then use those to get results in proper structures, instead of trying to parse textual output from a command. You will then also be free of any actual textual representation of records.
I am using ASP.NET Web Api 2 with Json.NET 6.0.1.
According to ISO 8601, dates should be interchanged in a certain way. I am using the IsoDateTimeConverter() in order to achieve this:
config.Formatters.JsonFormatter.SerializerSettings.Converters.Add(new IsoDateTimeConverter());
But how should "time of day" be returned in a JSON response model?
I cannot find anything for this in the ISO specification.
Should time perhaps be returned as a:
TimeSpan? (with expectation of the user to not use this as a duration representation)
DateTime? (with expectation of the user to drop off the date part)
A custom Time class
There is no standard structure in JSON for containing dates or times (see JSON.org). The de-facto stardard for dates-time values is using a string in ISO 8601 format, as you mentioned. But since there is no official standard it really comes down to what works best for you and consumers of your API.
Using a DateTime object is a reasonable choice because the support already exists in Json.Net and other serializers for converting these to and from ISO 8601 strings. So this would be the easiest to implement. However, users of your API would have to know to disregard the date portion, as you said. You could set the date to 0001-01-01 to emphasize its irrelevance. This isn't so different from the more common situation where you need only a date in your API and the time doesn't matter. Most people just set the time to midnight in this case and let it go. But, I would agree that this approach does seem to have a little bit of a "code smell" to it, given that part of the value is just noise.
Perhaps a cleaner idea is to format your DateTime value as ISO 8601, but then chop off the date portion before returning it. So users of the API would get a string that looks like 14:35:28.906Z. You could write a simple JsonConverter to handle this for you during serialization. This would sort of give you the best of both worlds -- a cleaner API, but you still can work with the familiar DateTime struct internally.
A custom Time class could also work here, but might be overkill, depending. If you do need to go there, you might want to look into a third-party library such as Noda Time, which has classes already built for these kinds of things, and also has pre-built converters for Json.Net.
I would definitely not choose TimeSpan for this purpose. Wrong tool for the job.
I have a shell script (zsh, to be precise) which uses
strftime "%I:%M %p %Z (%a, %b %d)" "$EPOCHSECONDS"
to generate a "current time" such as
"02:45 PM CST (Thu, Mar 01)"
This needs to be able to display the time in several different USA timezones, and so I have been using 'US/Eastern', 'US/Central', and 'US/Pacific' like so:
export TZ='US/Eastern'
strftime "%I:%M %p %Z (%a, %b %d)" "$EPOCHSECONDS"
That seems to work just fine, and I prefer it to using TZ='America/CityName' because it doesn't require me to know which city is in which TZ, I just need to tell it which TZ I want.
However, I happened across http://www.php.net/manual/en/timezones.others.php and saw that it says
Please do not use any of the timezones listed here (besides UTC),
they only exist for backward compatible reasons.
I don't know what the issues are with the US/Region names, but I'm curious to know if using them is likely to cause a problem in the foreseeable future, or are they still safe to use? Is it just PHP which doesn't like them, or is everyone moving away from them?
The standard format for naming timezones in the Olson database is Continent/City. The "old" names you mention like US/Eastern, US/Central, and many more, are listed as backward compatibility links in the tzdata source distribution (in the file "backward"). According to the comment at the top of the file, these names may have become backward compatibility links in late 1993.
I think I remember reading that this standard was adopted because it was felt to be more stable: geopolitical (country) boundaries change, cities never move around. Maybe also because names like "Eastern" and "Central" are thought to be more confusing because they mean different timezones in different parts of the world. However, I cannot find any references to the naming rationale at the moment, so don't quote me on this.
The Continent/City-style names are preferred. Notice that operating systems like Debian and Ubuntu ask you to select the system timezone using these names (unless they autodetect it at installation time), Using these names you wouldn't really be required to, as you say, "know which city is in which TZ" because the city name is, well, part of the timezone name! So if you happen to have learned the Continent/City names instead of or in addition to the Country/Region names, you're already OK.
That being said, I do not think that these names will ever disappear. On the timezone mailing list, they are definitely always called "backward compatibility", not "deprecated", and are intended to stay, notwithstanding what PHP recommends.
I have a requirement to handle custom date formats in an existing app. The idea is that the users have to do with multiple formats from outside sources they have very little control over. We will need to be able to take the format and both validate Dates against it, as well as parse strings specifically in that format. The other thing is that these can be completely arbitrary, like JA == January, FE == February, etc...
to my understanding, chronic only handles parsing (and does it in a more magical way then I can use), and enter code here DateTime#strptime comes close, but doesn't really handle the whole two character month scenario, even with custom formatters. The 'nuclear' option is to write in custom support for edge cases like this, but I would prefer to use a library if something like this exists.
I don't think something that handles all these problems exists if the format is really very arbitrary. It would probably be easiest to "mold" your input into a form that can be handled by Date.parse, Date.strptime, or another existing tool, even though that could mean quite a bit of work.
How many different formats are we talking about? Do any of them conflict? It seems like you could just gsub like so: input_string.gsub(/\bJA\b/i, 'January'). Is this part of an import routine, or are the users going to be typing in dates in different formats?
There's a related question here: Parse Italian Date with Ruby