Why does the ToUniversalTime function have no effect here;
DateTime dt = new DateTime(2009,3,24,1,0,0,DateTimeKind.Local);
dt = dt.ToUniversalTime(); // convert BST to UTC ?
dt.ToString();
"24/03/2009 01:00:00" ... wrong?
Is the same as..
DateTime dt = new DateTime(2009,3,24,1,0,0,DateTimeKind.Utc);
dt = dt.ToUniversalTime(); // nothing to do, already utc
dt.ToString();
"24/03/2009 01:00:00" ... correct.
I expected there to be an adjustment to the ToString() value of the first example, where by the DateTime specified as Local would result in a corresponding TimeZone calculation upon the call to ToUniversalTime() and the time in the UK should have resulted in
"24/03/2009 00:00:00" as UTC.
However it appears like the specifying of the DateTimeKind in this way renders ToUniversalTime or ToLocalTime unable to make any calculation.
Are you in the UK by any chance? Although we are now in daylight saving time, the date you specify in your code is before this switched over, so local and UTC time in the UK are the same. If you specify April as your month, then you will see a one hour difference.
Cheers David M.
Not had my breakfast. Indeed, when I repeat the test with dates that elapse the BST summer-time threshold, the behaviour is of course correct.
DateTime dt = new DateTime(2009,4,24,1,0,0,DateTimeKind.Local);
dt = dt.ToUniversalTime(); // convert BST to UTC ?
dt.ToString(); // "24/04/2009 00:00:00" ... correct
And to confirm, the ToString() method appears to output based on the Kind property.
Related
I'm confused.
I have a textbox that is populated with a date and time (string) such as '09/07/2021 10:30'.
I convert this string to a moment like so:
var suggestedDateObj = moment(suggestedDate, 'DD/MM/YYYY HH:mm');
I then want to check if this date and time is in between time slots in a fullcalendar.js event object. I do this like so:
var startDateObj = moment(value.start);
var endDateObj = moment(value.end);
if (suggestedDateObj.isBetween(startDateObj, endDateObj)) {}
However...it isn't working. And it's due to timezone offset (i think).
suggestedDateObj returns a value with a UTC offset of +0100 (British Summer Time)
However my calendar event objects return a date with a UTC offset of +0000. So when i check if '09/07/2021 10:30 +0100' is in between '09/07/2021 10:30 +0000' and '09/07/2021 11:30 +0000' it doesn't work!
I guess my question is really either:
How can I create my suggestedDateObj moment with a timezone offset of zero? OR
How can i tell fullcallendar events that the time it is displaying is actually BST (+0100)? At the moment I don't specify the 'Timezone' parameter.
Thanks.
UPDATE
Hmm....this might work....although it feels a bit clunky:
var tmoment1 = moment(suggestedDate, 'DD/MM/YYYY HH:mm');
//create default date with specific timezone offset of zero
var suggestedDateObj = moment().utcOffset(0);
//set the date and time
suggestedDateObj.set({
day: tmoment1.day(),
month: tmoment1.month(),
year: tmoment1.year(),
hour: tmoment1.hour(),
minute: tmoment1.minute(),
second: 0
});
You can generate suggestedDateObj in utc like that:
var suggestedDateObj = moment.utc(suggestedDate, 'DD/MM/YYYY HH:mm');`
For the .isBetween() I suggest you to use the square bracket like forth parameter, like documentation says.
if (suggestedDateObj.isBetween(startDateObj, endDateObj, undefined, '[]'))
The square brackets indicate that the check must include the dates of the limiter
Currently I like to calculate the total time taken for my soap ui automation project using groovy. I tried the following approach but it doesn't work:
Date startTime= new Date()
Date EndTime= new Date()
But i unable to compare the dates since it is taking the data types as string "Sat May 18 23:54:29 IST 2019" and I am unable to find the difference.
In groovy you can use the TimeCategory utility to subtract your dates, and get a TimeDuration object representing the difference. From this object you can inspect all sort of structured time/duration information.
Also, if you have a date in a String representation you can parse it into a Date using Date.parse passing as a parameter the format of the string and the string representation itself.
The following is a working demo of all this:
import groovy.time.*
def startTimeString = "Sat May 18 00:00:00 IST 2019"
def startTime = Date.parse("E MMM dd H:m:s z yyyy", startTimeString)
def endTime = new Date()
use (TimeCategory) {
TimeDuration duration = endTime - startTime
println "[${startTimeString}] was [${duration}] ago"
}
Complete code on GitHub
Hope this helps.
I'm using Hibernate 5 & MySQL.
This is what is getting saved into the database: 2018-03-11 06:26:47.336 I don't think this is 24 hour format, but then how do I see AM/PM? And how do I save the time in 24 hour format?
Running SELECT ##global.time_zone; in MySQL shows me: +00:00 So I think I'm set for accepting UTC time? This is how I set my pojo's field for setting time:
Clock clock = Clock.systemUTC();
LocalDateTime userCreated = LocalDateTime.now(clock);
It accepts LocalDateTime. But what I get back from database when I query is: u1.getUserCreated(): 2018-03-11T01:26:47.336 And when I try to convert the time into zone specific, I get the below:
ZonedDateTime z1 = ZonedDateTime.of(u1.getUserCreated(), ZoneId.of("America/New_York"));
System.out.println("z1: " + z1);
// z1: 2018-03-11T01:26:47.336-05:00[America/New_York]
But it really should be: 9:26:47.336 PM (21:26:47.336) As you can see on this site: http://www.timebie.com/std/utc.php
You're just not converting correctly. Your LocalDateTime represents the wall-clock time in the UTC time zone. Not in the New York time zone. So yo need to transform it to a ZonedDateTime in UTC::
ZonedDateTime utcDateTime = u1.getUserCreated().atZone(ZoneOffset.UTC);
Then, if you want to get a ZonedDateTime for the same instant, but in the New York timezone, then, well, just do that:
ZonedDateTime newYorkDateTime = utcDateTime.withZoneSameInstant(ZoneId.of("America/New_York"));
My code looks like this
std::string date = "04/05/2015 02:07";
std::string format = "MM/dd/yyyy HH:mm";
QDateTime dateTime = QDateTime::fromString(date.c_str(), format.c_str());
bool isItValid = dateTime.isValid();
This is part of a function I have but I narrowed the problem to specifically that value for date. After executing, isItValid is false. Why is it not a valid date?
However, if I try
bool isItValid = dateTime.date().isValid() && dateTime.time().isValid();
the value is true.
Can anyone point out what's the problem with that date? what am I missing?
The documentatation of isValid() (http://doc.qt.io/qt-5/qdatetime.html#isValid) says:
Returns true if both the date and the time are valid and they are
valid in the current Qt::TimeSpec, otherwise returns false.
If the timeSpec() is Qt::LocalTime or Qt::TimeZone then the date and
time are checked to see if they fall in the Standard Time to Daylight
Time transition hour, i.e. if the transition is at 2am and the clock
goes forward to 3am then the time from 02:00:00 to 02:59:59.999 is
considered to be invalid.
So it seems it's the Qt::TimeSpec you are missing.
My code:
val pattern = "MM-dd-yy"
val t = DateTime.parse("07-01-86", DateTimeFormat.forPattern(pattern)).toDateTime(DateTimeZone.forID("GMT"))
val z = t.getMillis.asInstanceOf[Long]
println("ms= "+z) // expected output: 520560000000 actual output: 520578000000
Several online GMT date converters give a different millis output than DateTime. Anyone know why?
In your solution your local time zone is implicitly used when parsing the date time. You should use
val t = DateTime.parse("07-01-86", DateTimeFormat.forPattern(pattern).withZoneUTC())
to force the DateTime to be created in the UTC zone. Then, the millis is 520560000000. No need to execute toDateTime(DateTimeZone) on it any more.
Otherwise, with your construction
val t = DateTime.parse("07-01-86", DateTimeFormat.forPattern(pattern)).toDateTime(DateTimeZone.forID("GMT"))
the DateTime will be first created in your local TZ (ie. midnight of 07-01-86 in your TZ) and then "cast" to UTC, but preserving the timestamp (ie. it will be the same timestamp, but interpreted in UTC, so the time part and the day part will change depending on your local TZ offset).
Example (my TZ is +02:00):
DateTime.parse("07-01-86", DateTimeFormat.forPattern(pattern)) // --> 1986-07-01 00:00 (+02:00)
.toDateTime(DateTimeZone.forID("GMT")) // --> 1986-06-30 22:00 (UTC)
I assumed you are OK with using UTC over GMT but there's also
DateTimeFormat.forPattern(pattern).withZone(...)
where you can provide your desired zone.