I have a military time that I am trying to convert to a 12 hr am/pm format as shown below
console.log(moment("13:00", 'HH:mm').format('HH:mm a'));
console.log(moment("15:00", 'HH:mm').format('HH:mm a'));
But I am getting
13:00 pm
15:00 pm
as the output, when it should be 01:00 pm and 03:00 pm. Am I missing something on the code ?
moment docs are pretty clear on formatting - make sure to check them. "H" is 24 hour time. You want "h" instead (or hh for 0 prefixed).
console.log(moment("13:00", 'HH:mm').format('hh:mm a'));
Related
Someone in the "Europe/London" (UTC +0) Timezone created a Spreadsheet. They input the date "March 22 2019" into one of the fields. This represents the date 3/22/2019 0:00 UTC+O.
I'm in the "America/Los_Angeles" (UTC -7) Timezone. When I run a Google Apps Script and try to get the value, it's evaluated as:
Thu Mar 21 17:00:00 GMT-07:00 2019
This is accurate since 3/22/2019 0:00 UTC+O == 3/21/2019 17:00 UTC-7.
The problem is when I try to get the date programmatically, I'll get it as 21 instead of 22.
For example, if I try to run:
cellRange.getValue().getDate() // returns 21 even though the sheet shows the date as 22
This is because getDate() returns values "according to local time." The local script time is UTC-7, hence it's returning 21.
However, this causes a dissonance:
Spreadsheet date: 22 (i.e. the value I see in the sheet)
Programmatic date: 21 (i.e. the one returned by getDate() above)
This is problematic when I'm trying to use a function such as joinDateAndTime_() with "March 22 2019" as the date and 6am as the time, for example. This causes it to produce a date "March 21 2019 6:00 UTC-7" instead of "March 22 2019 6:00 UTC-7".
What is the best solution here?
Not a complete solution (I'll update soon)
It seems like this is what is happening:
The value is hard-coded as "March 22" (text).
When a user opens the sheet, no matter what timezone they are in, it'll assume it represents March 22 in the sheet's timezone. 3/22/2019 0:00 UTC+0
Once you read the value into a JavaScript Date, all date functions assume you want it in your current (aka the script's) timezone. 3/21/2019 17:00 UTC-7
Solution A: Just add the hours
Forget about the timezones. Instead of hardcoding the hours in a Date, just offset the date by the hours you want.
The only downside is you need to be certain that the date started at 0:00 according to whatever timezone it was in. (E.g. if they decided to write "March 22 2019 5:00", then you'll be offsetting the hours incorrectly.)
Solution B: Do some math
I'll update this soon, but eventually you might want a function sheetTimezoneOffset() that could be used like this:
function getDate(cellRange) {
var date = cellRange.getValue().getDate();
var extraneousHours = formatDate(date, "h", sheetTimezoneOffset());
date = date.addHours(-extraneousHours);
var offsetHours = 6; // e.g. for 6am
date.addHours(offsetHours);
return date;
}
Start 6/7/2018 13:00 - End 7/14/2018 10:00 = Unix Time 3186000
The above is 35 days and 23 hours, converted to seconds is 3106800
So the manual conversion is 22 minutes different (less) from converting the date/times to Unix Time Stamps and subtracting.
Why?
Let's assume that I have some dates like these:
2014-01-23 14:52 (today)
2014-01-22-15:35
2014-01-21 10:35
2014-01-20 09:45
2014-01-19 17:58
2014-01-18 14:05
2014-01-17 13:22
Now I need to take into account only the 5 previous days to the current day, so for me they will be:
2014-01-22-15:35
2014-01-21 10:35
2014-01-20 09:45
2014-01-19 17:58
2014-01-18 14:05
In SSIS I wrote the next instruction in a conditional split task:
date > DATEADD("DD",-5,GETDATE()) && date < DATEADD("DD",-1,GETDATE())
But the result that I am having depends of the HOUR in which I execute the work flow.
So, for instance, if I execute it TODAY (2014-01-23) at 13:42. I am not going to seeing 2014-01-22-15:35 because it is after a complete day consider the hour (13:42)
and what I need is to see all the data that have a date at any moment from yesterday.
My question is, how can I indicate that I need ALL the dates of the previous days from today at 00:00?. In other words, how can I compute this interval for ALL the hours of the previous 5 days without taking into consideration the hour of execution.
if you are doing this in SQL you can try to cast the dateTime to a date
Declare #today date = getdate()
Declare #now datetime = getdate()
Cast(#now as date) between dateadd("DD",-5,#today) AND dateadd("DD",-1,#today)
let me know if that helps?
I need to predict the next run of a daily job. For example, if my job runs everyday at 1:00:00 am, and my sysdate is Nov 7 11:20:00 am, then my next run will be at Nov 8 1:00:00 am
The below logic helps me to achieve the desired results. However, when i convert the date after adding no. days to the start date, unix considers the daylight saving and converts from PDT timezone to PST timezone and gives me a time lag of 1 hour. Instead of getting Nov 8 1:00:00 am, I am getting Nov 8 00:00:00 am as output.
I want to derive date without the day light savings. Can someone help me achieve this logic in UNIX?
CURR_DATE=`date "+%s"`
START_DATE=`date -d "19OCT2014 01:00:00" "+%s"` #start date when the job was run first
diff_quo=$(((($CURR_DATE - $START_DATE) / (86400))))
diff_quo=$(($diff_quo * 86400))
new_datetime=$(($START_DATE + $diff_quo + 86400 ))
DERIVED_DATE=`date -d"#$new_datetime" "+%b %d %H:%M:%S"`
Thanks,
Ekata
Sample data in csv format. Save in a file broken_posix.csv
Date
3/10/2012 23:00
3/11/2012 0:00
3/11/2012 1:00
3/11/2012 2:00
3/11/2012 3:00
3/11/2012 4:00
3/11/2012 5:00
3/11/2012 6:00
3/11/2012 7:00
3/11/2012 8:00
3/11/2012 9:00
3/11/2012 10:00
3/11/2012 11:00
3/11/2012 12:00
3/11/2012 13:00
3/11/2012 14:00
3/11/2012 15:00
3/11/2012 16:00
3/11/2012 17:00
3/11/2012 18:00
3/11/2012 19:00
3/11/2012 20:00
3/11/2012 21:00
3/11/2012 22:00
3/11/2012 23:00
3/12/2012 0:00
3/12/2012 1:00
3/12/2012 2:00
3/12/2012 3:00
3/12/2012 4:00
3/12/2012 5:00
3/12/2012 6:00
3/12/2012 7:00
3/12/2012 8:00
3/12/2012 9:00
3/12/2012 10:00
3/12/2012 11:00
So I have this file broken_posix.csv. I can read the file just fine with
a_var <- read.csv("broken_posix.csv")
Then I can convert it to posix using
a_var_posixct = as.POSIXct(strptime( as.character( a_var$Date) , '%m/%d/%Y %H:%M'))
or with
a_var_posixlt = strptime(as.character( a_var$Date) , '%m/%d/%Y %H:%M')
The problem occurs now though because when I use posixct, then I get 4 NA values in my string every year. When I use posixlt I get one NA value on March 11,2012 at 2 (daylight savings time)
You'll see what I mean when you run
which(is.na(a_var_posixct))
which(is.na(a_var_posixlt))
a_var_posixct[4]
a_var_posixlt[4]
The fourth value is always a NA value whenever you apply an operation even though it is clearly a date value for posixlt.
I've tried omitting the value only to end up messing up the rest of the posix string.
I've tried setting the posix string as itself, in an attempt to clear the NA flag, to no effect.
I've even tried setting it as a character value only to lose the hour and minute formatting.
I think that this situation occurs because of daylight savings time. It's very frustrating to deal with because when I try to run other functions on the dates I have to try to avoid the NA values since I can't change them. I could aggregate the data by day, and or just use date objects but that doesn't seem like the right method.
Using a time zone without daylight saving time fixes this kind of problems for me.
a_var_posixlt = strptime(as.character( a_var$Date) , '%m/%d/%Y %H:%M',tz="GMT")
from ?as.POSIXct
Character input is first converted to class "POSIXlt" by strptime: numeric input is first converted to "POSIXct". Any conversion that needs to go between the two date-time classes requires a timezone: conversion from "POSIXlt" to "POSIXct" will validate times in the selected timezone. One issue is what happens at transitions to and from DST, for example in the UK
as.POSIXct(strptime('2011-03-27 01:30:00', '%Y-%m-%d %H:%M:%S'))
as.POSIXct(strptime('2010-10-31 01:30:00', '%Y-%m-%d %H:%M:%S'))
are respectively invalid (the clocks went forward at 1:00 GMT to 2:00 BST) and ambiguous (the clocks went back at 2:00 BST to 1:00 GMT). What happens in such cases is OS-specific: one should expect the first to be NA, but the second could be interpreted as either BST or GMT (and common OSes give both possible values). Note too (see strftime), OS facilities may not format invalid times correctly.
Your 4 NA's will presumably be on the hour when the clocks change twice a year.
I can't reproduce the problem, but here are some things you can try.
The first thing to check is that your data is correct. Copy and paste the dataset from this question, and run it again on your machine. Do you still get the error? If not, you probably have a typo in your dataset. Also try the line suggested by David Robinson.
as.POSIXlt(strptime("3/11/2012 2:00", '%m/%d/%Y %H:%M'))
Does this return NA?
Another source of weird date-related NAs is the locale. Check what yours is using
Sys.getlocale("LC_TIME")
Then change it to a different one. The available locales differ depending upon your OS (it's a mess), but take a look at example(Sys.setlocale).