An API returned time in this format:
"05/29:00:45"?
It was probably manually entered.
I understand how to parse it but is this a common time format in some countries or software?
the format is month/Day and time (hours/second). Probably the correct format it will be 05/29/00:45
Related
If a date is specified in the format
start=2021-04-05&end=2021-05-05
does that mean that 2021-05-05 is excluded from the results?
and it's returning up to 11:59:59 on the 4th?
In an API I'm using, it seems to be behaving the same as
start=2021-04-05T00:00:00Z&end=2021-05-05T00:00:00Z when no time is specified.
A few things:
I think you are asking about the full-date format from RFC 3339, which is the same as the ISO 8601 extended date format: YYYY-MM-DD
Neither specification says anything about inclusivity or exclusivity of date-only ranges.
ISO 8601 does talk a bit about ranges (they call them intervals), but they are defined as a pair of instants, not whole dates.
The typical best practice (in my experience) would be to use a fully inclusive range for date-only values, or a half-open range for date-time values. For example:
[2021-04-05, 2021-05-05]
[2021-04-05T00:00:00, 2021-04-06T00:00:00)
However, this is not a hard rule. The actual details would be highly specific to the particular API you are using and how the authors of that API designed it to function.
A whole date like 2021-04-05 is not necessarily the same thing as 2021-04-05T00:00:00. In many cases, the reason to use a whole date is to not associate a time or a time zone at all. But again, this is highly implementation specific.
Nothing you've shown would imply that UTC (Z) is being used. If that's how the API is behaving, that's another implementation detail of that API.
In Slack, when using date formatting, such as <!date^1392734382^{date_num}|fallback text>, is it possible to send the current date/time instead of providing a specific Unix time?
No. This function is just for formatting. So you need to provide timestamp.
But most programming languages have a standard function that returns the current UTC time as UNIX epoch, which you can use.
For example in Python you would do:
from time import time
timestamp = int(time())
I am doing a simple query to retrieve data via ODBC and OdbcDataReader. However, I am not able to determine what the time zone of the data returned is. I have checked every doc and nothing tells me what it is (UTC or local). I tried to look for a setting in SQL Plus and was unable to find something there either.
Does anyone know or know what docs would say? Thanks!
#Madgui is correct with the timezone information. However, there was something else I wanted to mention.
In SQLplus, if you use SELECT ISO8601(IP_TREND_TIME) in your query, you will be returned an ISO8601 string.
If you are doing something in let's say C# and need this as a UTC time, you would have to do the following:
DateTime.SpecifyKind(DateTime.Parse(datareader["TREND_TIME"].ToString()).ToUniversalTime(), DateTimeKind.Utc)
DateTim.Parse will return as a LOCAL time, just an FYI which is why you need to to the .ToUniversalTime(). Also, never a bad idea to classify as UTC.
In AspenTech IP21 SqlPlus, every timestamps you are relevant to server timezone. If you are only interested in UTC offset (beware, timezone is not just that), you can ask the server its current time, and do the calculation:
--something like that :
WRITE GETDBTIME;
Also, if you have right on the server, you could call a system command (check the doc for the correct syntax) to have the name of the Timezone:
SYSTEM 'tzutil /g';
The best way to work using timezones in InfoPlus is ever use the function ISO8601(timestamp here). This way you avoid timezones conversions mistakes.
I am trying to use Mailchimp.com's API 3.0 to add people from a PHP web server, but my datetime values for "timestamp_signup"and "timestamp_opt" are being rejected on insert subscriber.
According to this page :
https://developer.mailchimp.com/documentation/mailchimp/reference/lists/members/
the format of timestamp_signup and timestamp_opt is ISO 8601 format and both are writeable.
But all the versions I have tried have been rejected:
"2018-10-19T13:50:37+01:00"
"2018-10-19T13:50:37"
"2018-10-19T13:50"
"2018-10-19"
Many thanks
Ian
What is the correct format?
Great find Ian, that seems to be a new issue within the MailChimp API that occurred first with us around a week ago, but it seems to also not happen always.
I contacted the MailChimp Support and they confirmed it seems to be a problem on their end and that they will look into it.
For now I can confirm that your workaround (YYYY-MM-DD HH:MM:SS) works fine but it is not what the MailChimp API states and should definitely be fixed by them.
The format to use is YYYY-MM-DD HH:MM:SS
Not ISO 8601 which is YYYY-MM-DDTHH:MM:SS+HH:MM
Mailchimp.com's software generated correct ISO8601 dates when it sends datetimes back. However it requires the "T" to be a space, and will reject a date that includes the timezone (the +HH:MM on the end).
This is contrary to my reading of the standard.
#Ian is correct. The right format is not ISO 8601 but the classic one:
YYYY-MM-DD HH:MM:ss
Be careful if you're using JS/NodeJS with momentJS for instance. The right format is the following:
moment().format("YYYY-MM-DD HH:MM:ss")
The seconds are in lower case. Otherwise, you will have the fractional value which results in an error on the Mailchimp side.
I am saving all my notes in a log file. Each line is a note, suffixed by tags, and prefixed by a date and time marker, which currently looks like this: [12.20.09:22.22] ([date:time].
I am planning to have this a long-living format. Notes will be logged willy-nilly with this format 20-30 times a day for years to come. I foresee numerous kinds of parsing for analytics, filtering, searching ...
I am worried about the [ ]s though. Could they possibly trip some parsing code (someone else's if not mine)? What would be the most non-confrontational marker?
If you end up going with your own format, can I recommend ISO 8601 for your date and time format.
In summary, the basic format is:
yyyy-mm-dd hh:mm:ss
You can extend this with timezone and microsecond info if you wish. Timezone is recommended or assume UTC.
With the date/time in this format there's no confusion over which is the month and the day. And it has the bonus of sorting using a basic string sort.
I'd consider using either XML or JSON as the format for the file.
In particular your date/time marker is ambiguous. Is it mm/dd/yy or dd/mm/yy? Or even yy/mm/dd? And in what timezone is the date and time?
Both XML and JSON define a way to have dates that are culture and timezone independent, and (best of all) there's masses of tooling available for both formats.
XML datetime format is defined here: for example, 2000-01-12T12:13:14Z.
JSON datetime format is defined as the number of seconds since Jan 1, 1970, so it's a bit uglier: { currentDate: "#1163531522089#" }
If you want everything to last in a long-lived format, then the metadata needs to be as explicit as possible. If it's intended to be long-lived, then many others will need to read it, as easily as possible.
I agree with Jeremy McGee: XML is an excellent choice. Even if no other data lives, then having it be in the format:
<note>
<datetime>
<year>
2009
</year>
<month>
12
</month>
. . .
</datetime>
<message>
Foo bar baz quox
</message>
<note>
cannot be misunderstood.
This depends on your data. However, if you escape them with a special character of some sort, (i.e. \]) and code accordingly to look at the previous character when finding a "[" or "]", you should have no problem.
Also, if you're open to a new format, I'm a fan of JSON as it's light weight and very useful.
Using '[]' as the markers would be ok provided that you allow the DSL the ability to escape the characters. This is typical of operations on text which need parsing.
As an example check out the typical regular expression syntax which enables '/' as the seperator, whilst letting the user specify an escape character such as '\'. You may get some more ideas from the likes of such Unix tools as; awk, sed and grep
I would tend to think a standardized format is the way to go, with JSON being my personal choice because of it's simplicity. Not only does that help to avoid parsing issues since others have already though about it, you are also given a lot more tools to work with over the life of the project.