Hi I am wonder about how to set the time to live in dynamo db.
I understand that I have to create a field, could be called ttl and set the value to be deleted, but in which format innodejs do I have to save to use for the ttl field for 20 or 24 hours?
Thanks for help.
From the official DynamoDB documentation:
TTL compares the current time in epoch time format to the time stored
in the Time To Live attribute of an item. [...]
Note
The epoch time
format is the number of seconds elapsed since 12:00:00 AM January 1st,
1970 UTC.
In Javascript, you can get the number of milliseconds since the epoch by doing Date.now(). Once you have that, you can divide everything by 1000 to get the seconds (also rounding to the nearest integer value) and finally add the number of seconds in the TTL that you want.
This means that if you want to set the expiration time 24 from now, you can easily set the TTL field with the value expirationTime calculated this way:
const SECONDS_IN_AN_HOUR = 60 * 60;
const secondsSinceEpoch = Math.round(Date.now() / 1000);
const expirationTime = secondsSinceEpoch + 24 * SECONDS_IN_AN_HOUR;
Related
I would like to restrict some actions if date is on sunday - e.g. do not allow create item on Sunday.
I use:
public isSunday(date: Date): boolean {
return date.getDay() === 0;
}
My problem is that my UTC offset is UTC+2.
Server and database runs on UTC TZ to prevent unwanted date and time shifts.
When I send datetime from frontend I use date.toISOString(), so my local datetime
2022-05-16 00:00:00 is converted to string 2022-05-15T22:00:00:000Z
When I check this date on the backend side, this date IS sunday, but in the UTC zone, not my local zone.
String value is converted to Date at the backend using following
new Date(input);
Edit: Value 2022-05-16T01:41:00+02:00 (sending value with utc offset info) does not work either
To my understanding, you need the local (UTC+2) zone on the back-end for only Sunday checks.
You can simply subtract 2 hours equal to milliseconds from the date received on the backend before the Sunday checks.
// ... get date here
date -= (2 * 60 * 60 * 1000); // subtract 2 hours
I don't think this is a good practice as your frontend may change its timezone but you can try this.
const date = new Date("2022-05-16 00:00:00")
const corrected_date = new Date(date.valueOf() - 7200000) //subtract milliseconds as needed, in this case 2*60*60*1000
console.log(corrected_date.getDay())
If possible, then you should maybe try sending the UTC offset as a seperate parameter to the backend and calculate the correct value to be subtracted for it to work dynamically.
Validate the date field to be greater than x days from now.
Right now I have this snippet that checks if the date is greater than now.
planned_date: Joi.date().greater('now').required()
But I want to validate that the planned_date is at least 2 days more than now.
This could be possible combining with moment.js, but couldn't get it working.
This will check for date greater than 2 days, what we are doing is using Date.now() to get current time stamp in epoch later adding 2 days time in epoch to get the validation we wanted.
planned_date: Joi.date().required().greater(Date.now() + 48 * 60 * 60 * 1000)
I am trying to write a basic script that can read in a timestamp as a string and convert it into milliseconds. The timestamps I am working with are in minute:second.millisecond format.
from datetime import datetime
timestamp_start = '54:12.123'
MSM = '%M:%S.%f'
zero = '00:00.000'
start_sec = (datetime.strptime(timestamp_start, MSM) - datetime.strptime(zero, MSM)).total_seconds()
start_ms = start_sec * 1000
print(start_ms)
This may be a round about approach, but I am first using datetime.strptime to get a datetime object, then subtracting by 0 in order to get a timedelta object, getting the total seconds of the timedelta object, and finally multiplying by 1000 to convert to milliseconds.
The above code works fine, except for any timestamps over an hour.
The issue that I am running into- the timestamps do not have an hour counter. For example: 1 hour, 5 minutes, and 30 seconds comes in as 65:30.000. datetime.strptime cannot recognize this format, as it only allows the minutes to be between 0 and 59.
How can I convert these timestamps into a format recognizable by datetime? Should I first get the timestamp into hour:minute:second:millisecond format? Keep in mind the end goal is to convert these timestamps into milliseconds. If there is a better approach any suggestions are more than welcomed!
'54:12.123' isn't really a timestamp, but elapsed time, and there's no built-in method in Python that can deal with elapsed time with a format string like a timestamp format.
Since the format string in question is simply minutes and seconds separated by a colon, and seconds and milliseconds separated by a period, you can easily parse it with the str.split method:
def convert(msf):
minutes, seconds = msf.split(':')
seconds, milliseconds = seconds.split('.')
minutes, seconds, milliseconds = map(int, (minutes, seconds, milliseconds))
return (minutes * 60 + seconds) * 1000 + milliseconds
so that convert('54:12.123') returns:
3252123
I have documents in my mongodb, this documents have event field - this fild type is date. The year, month , day, does not matter, means only the time during day. I want the cron script,every day, to aggregate from mongodb the documents with the event (date typed) field to be in nearest 10 minutes (to the script calling date). How to implement it in right way?
db.mytable.find(
{
"event": {
$gt: new Date(new Date().getTime() - (10 * 60 * 1000))
}
})
This query will find all documents that have an "event" property with a value within the past 10 minutes. new Date() without arguments returns a Date representing "right now". We pull the numeric epoch time in milliseconds from that and subtract 10 minutes. More specifically, we subtract (10 minutes * 60 seconds per minute * 1000 milliseconds per second), so that we convert to the correct units. We then use that value to construct another new Date(...), and this is the one that goes into the $gt (greater-than) filtering condition.
You mentioned a need for "aggregation". If so, then this same query can also be used within any Aggregation Pipeline that you need.
Has anyone had to update a Duraton field from within a plugin?
On the UI it is fairly intelligent, you can type
5 minutes
7 //defaults to minutes
3 hours
And it will workout what you need.
Assuming the field is called new_foo, what value should I assign? Int?
var e = new Entity("new_bar");
e.Attributes("new_foo", 5);//5 minutes?
Double?
var e = new Entity("new_bar");
e.Attributes("new_foo", 5.00);//5 minutes?
Other ideas?
Duration is a format for the Whole Number type, so by code you need to set an Int32 value (in this case not negative or it will throw an exception)
The value is always considered in minutes, so if you want to put 3 hours you need to set the field value to 180 (60 minutes x 3 hours), 1 day is 1440 (60 minutes x 24 hours) and so on.
By interface you can set using decimals, but it's always a representation of an integer value (for example 1.5 hours equals 90 minutes)