With java.time , I'm trying to format the time as the following "2018-03-15T23:47:15+01:00" .
With this formatter I'm close to the result in Scala.
val formatter: DateTimeFormatter = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ssZ")
ZonedDateTime.now() // 2018-03-14T19:25:23.397+01:00
ZonedDateTime.now().format(formatter) // => 2018-03-14 19:25:23+0100
But I cannot insert the extra character "T" between the day and hour.
What does this "T" mean BTW ?
How to format as "2018-03-15T23:47:15+01:00" ?
Notes:
In case you wonder why LocalDateTime cannot be formatted
Format LocalDateTime with Timezone in Java8
Try this
val ZONED_DATE_TIME_ISO8601_FORMATTER3 = DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ss.SSSxxx")
ZonedDateTime.now().format(ZONED_DATE_TIME_ISO8601_FORMATTER3)
// 2018-03-14T19:35:54.321+01:00
See here
Offset X and x: This formats the offset based on the number of pattern letters. One letter outputs just the hour, such as '+01', unless the minute is non-zero in which case the minute is also output, such as '+0130'. Two letters outputs the hour and minute, without a colon, such as '+0130'. Three letters outputs the hour and minute, with a colon, such as '+01:30'. Four letters outputs the hour and minute and optional second, without a colon, such as '+013015'. Five letters outputs the hour and minute and optional second, with a colon, such as '+01:30:15'. Six or more letters throws IllegalArgumentException. Pattern letter 'X' (upper case) will output 'Z' when the offset to be output would be zero, whereas pattern letter 'x' (lower case) will output '+00', '+0000', or '+00:00'.
Converting the ZonedDateTime to OffsetDateTime - as suggested in the other answers - works, but if you want to use a DateTimeFormatter, there's a built-in constant that does the job:
ZonedDateTime.now().format(DateTimeFormatter.ISO_OFFSET_DATE_TIME)
But it's important to note some differences between all the approaches. Suppose that the ZonedDateTime contains a date/time equivalent to 2018-03-15T23:47+01:00 (the seconds and milliseconds are zero).
All the approaches covered in the answers will give you different results.
toString() omits seconds and milliseconds when they are zero. So this code:
ZonedDateTime zdt = // 2018-03-15T23:47+01:00
zdt.toOffsetDateTime().toString()
prints:
2018-03-15T23:47+01:00
only hour and minute, because seconds and milliseconds are zero
The built-in formatter will omit only the milliseconds if it's zero, but it'll print the seconds, regardless of the value. So this:
zdt.format(DateTimeFormatter.ISO_OFFSET_DATE_TIME)
prints:
2018-03-15T23:47:00+01:00
seconds printed, even if it's zero; milliseconds ommited
And the formatter that uses an explicit pattern will always print all the fields specified, regardless of their values. So this:
zdt.format(DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ss.SSSxxx"))
prints:
2018-03-15T23:47:00.000+01:00
seconds and milliseconds are printed, regardless of their values
You'll also find a difference in values such as 2018-03-15T23:47:10.120+01:00 (note the 120 milliseconds). toString() and ofPattern will give you:
2018-03-15T23:47:10.120+01:00
While the built-in DateTimeFormatter.ISO_OFFSET_DATE_TIME will print only the first 2 digits:
2018-03-15T23:47:10.12+01:00
Just be aware of these details when choosing which approach to use.
As your question already shows, you may just rely on ZonedDateTime.toString() for getting a string like 2018-03-14T19:25:23.397+01:00. BTW, that string is in ISO 8601 format, the international standard. Only two minor modifications may be needed:
If you don’t want the fraction of second — well, I don’t see what harm it does, it agrees with ISO 8601, so whoever receives your ISO 8601 string should be happy to have it. But if you don’t want it, you may apply myZonedDateTime.truncatedTo(ChronoUnit.SECONDS) to get rid of it.
ZonedDateTime.toString() often appends a zone name, for example 2018-03-14T19:25:23+01:00[Europe/Paris], which is not part of the ISO 8601 standard. To avoid that, convert to OffsetDateTime before using its toString method: myZonedDateTime.toOffsetDateTime().toString() (or myZonedDateTime.truncatedTo(ChronoUnit.SECONDS).toOffsetDateTime().toString()).
Building your own formatter through a format pattern string is very flexible when this is what you need. However, very often we can get through with less (and then should do for the easier maintainability of our code): toString methods or built-in formatters including both the ISO ones and the localized ones that we can get from DateTimeFormatter.ofLocalizedPattern().
What does this "T" mean BTW ?
The T is part of the ISO 8601 format. It separates the date part from the time-of-day part. You may think of it as T for time since it denotes the start of the time part. If there is only a date (2018-04-25) or only a time-of-day (21:45:00), the T is not used, but when we have both, the T is required. You may think that the format might have been specified without the T, and you are probably right. When it comes to the format for periods/durations it is indispensable, however, and also needed when there are no days: P3M means a period of 3 months, while PT3M means 3 minutes.
Link: Read more in the Wikipedia article on ISO 8601.
Related
I've looked for help on the internet for the following, but I could not find a satisfying answer: for an assignment, I need to plot the time series of a certain variable (the term spread in percentages), with years on the x-axis.
However, we use daily data. Does anybody know a convenient way in which this can be done? The 'date' variable that I've got is formulated in the following way: 20111017 represents the 17th of October 2011.
I tried to extract the first 4 numbers of the variable 'date', by using the substr(date, 1, 4) command, but the message 'type mismatch' popped up. Also, I'm not quite sure if it gives the right information if I only use the years to plot daily data (over the years). It now gives the following graph, which doesn't look that nice.
Answering the question in your title.
The date() function expects a string. If your variable with value 20111017 is in a numeric format you can convert it like this: tostring datenum , gen(datestr).
Then when using the date() function you must provide a mask that tells Stata what format the date string is in. Below is a reproducible example you can run to see how this works.
* Example generated by -dataex-. For more info, type help dataex
clear
input float datenum
20111016
end
* Convert numberic varaible to string
tostring datenum , gen(datestr)
* Convert string to date
gen date = date(datestr, "YMD")
* Display date as date
format date %td
If this does not help you, try to provide a reproducible example.
This adds some details to the helpful answer by #TheIceBear.
As he indicates, one way to get a Stata daily date from your run-together date variable is convert it to a string first. But tostring is just one way to do that and not essential. (I have nothing against tostring, as its original author, but it is better suited to other tasks.)
Here I use daily() not date(): the results are identical, but it's a good idea to use daily(): date() is all too often misunderstood as a generic date function, whereas all it does is produce daily dates (or missings).
To get a numeric year variable, just divide by 10000 and round down. You could convert to a string, extract the first 4 characters, and then convert to numeric, but that's more operations.
clear
set obs 1
gen long date = 20111017
format date %8.0f
gen ddate = daily(strofreal(date, "%8.0f"), "YMD")
format %td ddate
gen year = floor(date/10000)
list
+-----------------------------+
| date ddate year |
|-----------------------------|
1. | 20111017 17oct2011 2011 |
+-----------------------------+
Hello i have varchar column with datetime.
its utc
|2022-02-09T13:27:17.165116Z
|2022-02-09T13:27:27.3850848Z
|2022-02-09T13:28:18.5537284Z
on select query parse as by standart but return 'null' for all rows:
PARSE_TIMESTAMP(entrydate, 'yyyy-MM-ddTHH:mm:ss.SSSZZZZ')
code:
JsonSerializer.Serialize(DateTime.UtcNow);
This is because ksqldb only supports up to millisecond precision see https://www.confluent.io/blog/ksqldb-2-0-introduces-date-and-time-data-types/
There is a github issue tracking support for finer time resolution like microseconds here https://github.com/confluentinc/ksql/issues/8243
The problem is your DateFormat, yyyy-MM-ddTHH:mm:ss.SSSZZZZ which expects a precision of milliseconds but, from your input, it's microseconds.
To cover all the scenarios (as you are serializing it with JsonSerializer.Serialize, and it can happen that you don't even have anything after the seconds, or, milliseconds is zero: 2022-02-09T13:28:18Z) you would need to use the following format:
'yyyy-MM-dd''T''HH:mm:ss[.SSSSSSS][.SSSSSS][.SSSSS][.SSSS][.SSS][.SS][.S]''Z'''
This will cover all the use cases with/without the milliseconds/microseconds precision
More about the formatting:
https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html
So we use the following formatting options to specify that the precision is optional:
[ optional section start
] optional section end
and
S fraction-of-second fraction 978
note that you also have to 'escape' the letters:
https://docs.ksqldb.io/en/latest/developer-guide/ksqldb-reference/create-stream/#timestamp_format
Possible improvement (give it a try):
PARSE_TIMESTAMP(entrydate, 'yyyy-MM-dd''T''HH:mm:ss[.SSSSSSS][.SSSSSS][.SSSSS][.SSSS][.SSS][.SS][.S]X', 'UTC')
(you have to specify timezone so that it can parse the X to a correct timestamp including the zone)
from the Java DateTimeFormatter docs:
Pattern letter 'X' (upper case) will output 'Z' when the offset to be output would be zero, whereas pattern letter 'x' (lower case) will output '+00', '+0000', or '+00:00'.
My collegue (who has left the company) has written a bunch of scripts, including batch and Perl scripts, and I'm getting rid of the regional settings dependencies.
In the last Perl script, he's written the following piece of code:
my $format = "%d.%m.%Y %H:%M";
my $today_converted = Time::Piece->strptime($today, $format) - ONE_HOUR - ONE_HOUR - ONE_HOUR - ONE_HOUR - ONE_HOUR;
(the idea is to get five hours before midnight of that particular date)
The value of $today seems to be "03/04/2017" (which stands for the third of April (European dateformat)), which seems not to be understood by Time::Piece implementation:
Error parsing time at C:/Perl64/lib/Time/Piece.pm line 481.
Which format can I use which is understood by Time::Piece Perl implementation?
In the format you have dots . as the date delimiter, but in the data you have slashes /. That's why it doesn't parse. It needs an exact match.
I think it's worth clarifying that strptime() will parse most date and time formats - that's the point of the method. But you need to define the format of the date string that you are parsing. That's what the second parameter to strptime() (in this case, your $format variable) is for.
The letters used in the format are taken from a standard list of definitions which used by every implementation of strptime() (and its inverse, strftime()). See man strptime on your system for a complete list of the available options.
In your case, the format is %d.%m.%Y %H:%M - which means that it will parse timestamps which have the day, month and year separated by dots, followed by a space and the hours and minutes separated by a colon. If you want to parse timestamps in a different format, then you will need to change the definition of $format.
perl code:
#!/bin/env perl
use DateTime;
print DateTime->now;
OUTPUT:
2013-01-28T06:02:33
what's mean of 'T' letter in the output string ?
ISO8601 and RFC3339 both use "T" to join the date and the time, and DateTime's default stringifier apparently adopted that convention. If you want another format, you can use one of the DateTime::Format::* modules or ->strftime.
my $now = DateTime->now( time_zone => 'local' );
say $now->strftime('%Y-%m-%d %H:%M:%S');
It stands for "Time". You can read more at:
http://en.wikipedia.org/wiki/ISO_8601#Combined_date_and_time_representations
It's the separator between date and time in ISO 8601. It's always a T in this format.
The character [T] shall be used as time designator to indicate the start of the representation of the time of day
component in these expressions. The hyphen [-] and the colon [:] shall be used, in accordance with 4.4.4, as
separators within the date and time of day expressions, respectively, when required.
NOTE By mutual agreement of the partners in information interchange, the character [T] may be omitted in
applications where there is no risk of confusing a date and time of day representation with others defined in this
International Standard.
--Data elements and interchange
formats — Information interchange —
Representation of dates and times, ISO 8601:2004(E)
I'm writing a perl script that takes a "duration" option, and I'd like to be able to specify this duration in a fairly flexible manner, as opposed to only taking a single unit (e.g. number of seconds). The UNIX at command implements this kind of behavior, by allowing specifications such as "now + 3 hours + 2 days". For my program, the "now" part is implied, so I just want to parse the stuff after the plus sign. (Note: the at command also parses exact date specifications, but I only want to parse durations.)
Is there a perl module for parsing duration specifications like this? I don't need the exact syntax accepted by at, just any reasonable syntax for specifying time durations.
Edit: Basically, I want something like DateTime::Format::Flexible for durations instead of dates.
Take a look at DateTime::Duration and DateTime::Format::Duration:
use DateTime::Duration;
use DateTime::Format::Duration;
my $formatter = DateTime::Format::Duration->new(
pattern => '%e days, %H hours'
);
my $dur = $formatter->parse_duration('2 days, 5 hours');
my $dt = DateTime->now->add_duration($dur);
Time::ParseDate has pretty flexible syntax for relative times. Note that it always returns an absolute time, so you can't tell the difference between "now + 3 hours + 2 days" and "3 hours + 2 days" (both of those are valid inputs to parsedate, and will return the same value). You could subtract time if you want to get a duration instead.
Also, it doesn't return DateTime objects, just a UNIX epoch time. I don't know if that's a problem for your application.
I ended up going with Time::Duration::Parse.