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())
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.
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 have unix timestamp in table, wants to show to user using Carbon. How can I achieve ?
e.g.
1487663764.99256 To
2017-02-24 23:23:14.654621
Did you check the carbon docs? I think this is what youre looking for:
Carbon::createFromTimestamp(-1)->toDateTimeString();
Checkout http://carbon.nesbot.com/docs/#api-instantiation
There are several ways to create Carbon instances described in the Carbon documentation, which is linked at the bottom of the project's README. The relevant section is this:
The final two create functions are for working with unix timestamps. The first will create a Carbon instance equal to the given timestamp and will set the timezone as well or default it to the current timezone. The second, createFromTimestampUTC(), is different in that the timezone will remain UTC (GMT). The second acts the same as Carbon::createFromFormat('#'.$timestamp) but I have just made it a little more explicit. Negative timestamps are also allowed.
So you can just do:
$carbon = Carbon::createFromTimestamp($dbResult['SomeTimestampColumn']);
If you really love your fluid method calls and get frustrated by the extra line or ugly pair of brackets necessary when using the constructor you'll enjoy the parse method:
Carbon::parse(1487663764);
Carbon::parse('first day of next month');
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
Is there a way to convert timezones like "America/Los_Angeles" to timezone shortname "PDT" in ruby?
The abbreviations are typically contextual - so "PDT" only applies while daylight saving time is in operation.
Judging by the documentation, if you format a Time with strftime and use a format string of %Z, you should get the time zone abbreviation.
Personally I dislike using the abbreviations, given that they're ambiguous and can cause a lot of confusion. (I've seen people using "PST" year-round, for example, referring to "7/20/2012 9:00 PST" for example - a date/time which makes no sense.) That's a different matter though :)
More explicit answer:
Time.now.in_time_zone("America/Los_Angeles").strftime('%Z')