I try to set the initial value of Variable (Type: Date) to "2023-01-04 01:05:30.0".
I tried every combination, but I always get an error that the syntax is wrong.
The better (and non-deprecated) approach would be to use LocalDate and turn it into a Date:
LocalDateTime.of(2015, Month.JULY, 29, 19, 30, 40).atZone(ZoneId.systemDefault()).toInstant())
Read up on LocalDate and LocalDateTime as they are extremely useful for date manipulations. Only convert back to Date when all is computed and you need it for the model. See https://www.baeldung.com/java-date-to-localdate-and-localdatetime
Related
I feel silly that I cannot figure this one out on my own.
I have dates coming from the CarbonBlack API e.g. 2022-02-15-172040 which are in UTC
The [datetime] type cast works fine if I remove the seconds portion of the string
PS M:\Scripts> [datetime]"2022-02-15-1720"
Tuesday, February 15, 2022 12:20:00 PM
I don't understand how it "knows" that is a UTC string. It is correct of course but I expected 5:20pm for the time portion. I wanted the seconds for the date so I went to parse exact as this doesn't match any format strings as far as I know
PS M:\Scripts> [datetime]::ParseExact("2022-02-15-172040", "yyyy-MM-dd-HHmmss" ,[Globalization.CultureInfo]::CurrentUICulture)
Tuesday, February 15, 2022 5:20:40 PM
Which is the time I expected but the incorrect time.
Why is the [datetime] working when I wouldn't expect it to and what do I need to do to the string or static method call for it to treat that as a UTC string with minimal manipulation?
This is because
([datetime]"2022-02-15-1720").Kind
yields 'Local', while
([datetime]::ParseExact("2022-02-15-172040", "yyyy-MM-dd-HHmmss",[CultureInfo]::InvariantCulture)).Kind
returns 'Unspecified'
If you want the result to handle the string as being Local time and then the result should be in UTC, use:
([datetime]::ParseExact("2022-02-15-172040", "yyyy-MM-dd-HHmmss",[CultureInfo]::InvariantCulture, 'AssumeLocal')).ToUniversalTime()
or
$date = [datetime]::ParseExact("2022-02-15-172040", "yyyy-MM-dd-HHmmss",[CultureInfo]::InvariantCulture)
[datetime]::SpecifyKind($date, 'Local').ToUniversalTime()
Going the other way around, so if you regard the date in the string represents UTC (Universal Time), and you want the result to be in
Local time , you need to do this:
[datetime]::ParseExact("2022-04-29-185121", "yyyy-MM-dd-HHmmss",[CultureInfo]::InvariantCulture, 'AssumeUniversal')
Here, ParseExact() treats the string as UTC and outputs a date converted to Local time
(.Kind --> 'Local'), which is the exact same output as
[datetime]"2022-04-29-1851"
would give: also here, .Kind --> 'Local'`
If then you want the resulting date to be in UTC, you need to convert it back again with .ToUniversalTime()
The tricky part is that using ParseExact() without the third parameter ('AssumeLocal' or 'AssumeUniversal') when parsing a string that has no
indication of it being Local or UTC like the example strings here, is always returning a datetime object with its .Kind property set to Unspecified.
Thanks to mklement0's comment,
in PowerShell (Core) 7+, strings like in the example are no longer recognized and should have a TimeZone indication like '2022-02-15 17:20Z'. ('Z' --> Zulu (UTC) Time)
If you do give it the third parameter, telling it what timezone it should use ('AssumeLocal' or 'AssumeUniversal'), the resulting datetime object will
always have its .Kind property set to Local and the result will be converted to local time in case you have given AssumeUniversal as parameter.
With today's date, I should get the 16th date of next month.
For example, on passing 13-12-2021, I should get 16-01-2022.
I need to get the next month 16th day from current date (input date). Examples:
On passing 13-11-2021 should get 16-12-2021.
On passing 14-11-2021 should get 16-12-2021.
On passing 15-11-2021 should get 16-12-2021.
On passing 02-12-2021 should get 16-01-2022.
On passing 03-12-2021 should get 16-01-2022.
On passing 03-01-2022 should get 16-02-2022.
On passing 04-01-2022 should get 16-02-2022.
Any help will be much appreciated. Thanks.
java.time
One of the many strong points of java.time, the modern Java date and time API, is date arithmetic like this.
public static LocalDate nthDayOfFollowingMonth(
int desiredDayOfMonth, LocalDate currentDate) {
return YearMonth.from(currentDate)
.plusMonths(1)
.atDay(desiredDayOfMonth);
}
Try it out with your example date:
System.out.println(nthDayOfFollowingMonth(
16, LocalDate.of(2021, Month.DECEMBER, 13)));
Output:
2022-01-16
We might not have needed to convert to YearMonth and back to LocalDate. Doing so relieves both me and the reader of considering what happens if today’s day of month doesn’t exist in next month — for example if current date is 30 January (there is no 30 February). What one still wants to consider is what happens if you request a day of month tht doesn’t exist next month. For example on 13 January asking for the 30th of next month. We can try that out too:
System.out.println(nthDayOfFollowingMonth(
30, LocalDate.of(2022, Month.JANUARY, 13)));
I find the result very reasonable:
java.time.DateTimeException: Invalid date 'FEBRUARY 30'
Have a string object with a specific format of date.
Need to check if that dateStr is after the current time on local machine.
Having trouble with conversions and LocalDateTime
String dateStr = "Oct 27 2017 02:29:00 GMT+0000";
public static final String DATE_FORMAT = "MMM dd yyyy HH:mm:ss zzzZ";
I know something is fishy in the below code with the usage of LocalDateTime
public static boolean isFutureDate(String dateStr){
DateTimeFormatter formatter = DateTimeFormatter.ofPattern(DATE_FORMAT);
LocalDateTime dateTime = LocalDateTime.parse(dateStr, formatter);
return(dateTime.isAfter(LocalDateTime.now()));
}
Trouble is with timezones and date conversions.
Please help find the right way of checking if a dateStr is after the current local date this in Java 8?
Local… types have no time zone
You are using the wrong type for your data.
The Local… types including LocalDateTime purposely have no concept of time zone or offset-from UTC. As such they not represent a moment on the time line, only rough idea of a range of possible moments. Use LocalDateTime only when the time zone is unknown or irrelevant; never use it for an actual moment in history.
Use OffsetDateDate for values with an offset-from-UTC, a number of hours and minutes.
Use ZonedDateTime for values with an assigned time zone. A time zone such as Asia/Kolkata or America/Montreal is a particular region’s history of past, present, and future changes to its offset-from-UTC. Anomalies such as Daylight Saving Time (DST) mean a change to the offset.
If you know all your inputs are in GMT/UTC, use OffsetDateTime. If the inputs may use time zones, parse as ZonedDateTime objects.
This input data format is terrible. If you have any control, use standard ISO 8601 formats instead when exchanging date-time values as text.
All this has been covered many times already on Stack Exchange. Please search more thoroughly before posting. And search Stack Overflow to learn more. I kept my Answer here brief, as this is a duplicate.
When parsing to a LocalDateTime, you're ignoring the offset (+0000), and I'm not sure if that's what you really want.
In this case, the +0000 offset means the date/time is October 27th 2017 at 02:29 AM in UTC. When you parse to a LocalDateTime, you're ignoring the offset (so it represents only "October 27th 2017 at 02:29 AM", not attached to any timezone) and comparing to your local date/time (or the current date/time in the JVM's default timezone).
If you want to make a comparison that also considers the offset, you can parse it to OffsetDateTime and convert to Instant to compare it with the actual UTC instant, regardless of the timezone.
Also, the month name is in English (I'm assuming it's English, but you can change this accordingly), so you must a java.util.Locale in the formatter (if you don't set a locale, it'll use the JVM default, and it's not guaranteed to always be English):
// parse to OffsetDateTime (use the same formatter)
String dateStr = "Oct 27 2017 02:29:00 GMT+0000";
DateTimeFormatter fmt = DateTimeFormatter.ofPattern("MMM dd yyyy HH:mm:ss zzzZ", Locale.US);
OffsetDateTime odt = OffsetDateTime.parse(dateStr, fmt);
// compare Instant's
System.out.println(odt.toInstant().isAfter(Instant.now()));
Although it works for you now, keep in mind that the default locale can be changed without notice, even at runtime. If your input has locale-sensitive date (such as month names), it's better to specify it as above.
How can I create (Ecto.)DateTime out of a tuple {DD, MM, YY}, or parse it from a string in Elixir? Should I use DateTime from Erlang for that?
I've googled but haven't found anything and there's nothing in the documentation about the matter, only about DateTime in general -- how to get the current date and time, for example.
Note that I don't want to use a third-party library such as Timex.
Just adding to the answer given by Justin. Elixir's standard library can parse ISO 8601 dates.
iex> Date.from_iso8601("2015-01-23")
{:ok, ~D[2015-01-23]}
or with the bang-version, that might raise errors:
iex> Date.from_iso8601!("2015-01-23")
~D[2015-01-23]
If you want a full datetime from an ISO 8601 string, you'll have to be satisfied with a NaiveDateTime, since there's no reliable time zone information to go on.
iex> NaiveDateTime.from_iso8601("2015-01-23 23:50:07")
{:ok, ~N[2015-01-23 23:50:07]}
Beware, it will simply throw away time zone offsets.
There is going to be a from_iso8601/1 on DateTime in the future, but it was recently added and has not been released as of Elixir v1.3.4. It will preserve time zone offset, but set the time zone to UTC.
To get the current date and or time, you can use one of
Ecto.Date.utc
Ecto.Time.utc
Ecto.DateTime.utc
DateTime.utc_now
As for converting a {DD, MM, YY} tuple into an Ecto.Date, you will not be able to do that with ecto provided functions. However, you can use a {YYYY, MM, DD} tuple to convert into Ecto.Date.
Ecto.Date.from_erl({2016, 12, 4})
#Ecto.Date<2016-12-04>
Date.from_erl({2016, 12, 4})
{:ok, ~D[2016-12-04]}
Ecto.Time.from_erl({13, 55, 10})
#Ecto.Time<12:10:08>
Ecto.Time.from_erl({13, 55, 10})
{:ok, ~T[13:55:10]}
Ecto.DateTime.from_erl({{2016, 12, 4}, {13, 55, 10}})
#Ecto.DateTime<2016-12-04 13:55:10>
Ecto.Date.from_erl({2016, 12, 4}) |> Ecto.DateTime.from_date()
#Ecto.Date<2016-12-04>
You just need to make sure your data is in the proper order these functions expect them to be.
As for parsing these from a string, you are either going to need to bring in another library, or write a parser yourself.
As Martin Svalin and Erik Vullings already commented here, you can now parse strings to DateTime in pure Elixir:
iex(5)> {:ok, date_time, offset} = DateTime.from_iso8601("2018-03-17 21:23:12+0100")
{:ok, #DateTime<2018-03-17 20:23:12Z>, 3600}
As you can see, I set an offset of +1 hour in my string. It was parsed correctly, but a DateTime object doesn't keep timezone information, and when I print it, it displays the correct date and time, but printed by default in UTC.
If you want to keep the original timezone information, that's stored as an offset in seconds in the third element of the tuple (offset in my example above).
I have a ISO8601 string (e.g. date="2015-07-10T04:31:25") I need to convert this to the format:
July 7, 2015, 4:31:25 PM (EDT)
Even though I can write a template and use substring() to transform the string in the date time format. However I am not sure how to achieve the AM/PM and time zone information?
Working code templates would be highly appreciated. Thanks!
I am not sure how to achieve the AM/PM ...
It can be calculated from the hour component as:
substring('AMPM', 1 + 2*(number($hour) > 11), 2)
Of course, in the given input, where $hour would be "04", the correct result is "AM", not "PM".
... and time zone information?
Your input does not contain any time zone information, so unless you want to hard-code EDT as a string, there is no way to get it.