I am developing an attendance tracking system where user can check-in and check-out and system will capture the attendance date.
Let me give you inputs theoretically here:
Name: User A
Assigned Shift: 19:00 -- 03:00 (night shift)
Multiple checkins-checkouts allowed.
Use case 1:
Date: 2022-12-01
Check in
Check out
Expected Attendance date
2022-12-01 18:00
2022-12-02 02:00
2022-12-01
Use case 2:
Date: 2022-12-01
Check in
Check out
Expected Attendance date
2022-12-01 18:00
2022-12-02 00:00
-
2022-12-02 01:00
2022-12-02 02:00
2022-12-01
Use case 3:
Date: 2022-12-02
Check in
Check out
Expected Attendance date
2022-12-02 01:00
2022-12-02 02:00
2022-12-01
Use case 4:
Date: 2022-12-02
Check in
Check out
Expected Attendance date
2022-12-02 04:00
2022-12-02 04:15
2022-12-01
I need your help to develop an algorithm which will predict the attendance date when provided with shift timings (19:00 to 02:00) and user's time at that instance.
Related
Looking for support for the mentioned conditions.
If we put the Friday date then the formula would share the same week Thursday date. If the date is not Thursday then the same date would be there no changes are required.
Formula details which only giving Thursday. If no Friday then same date is required.
=IFS(AND(Y24="FRI",((S24-7)+MATCH(WEEKDAY(S24-7), {"","",2,1,7,6,5,4,3}, 0))))
Date Day Date Day
02/01/2015 Fri 01/01/2015 Thu
01/04/2015 Wed 07/05/2015 Thu
I need to assign a variable with the value in the format YYYYMM e.g for today run the previous month values should be generated as
Var1 = 201607
Is there any in build method available? Could you share the steps to generate this?
The trick in these cases is to subtract one month from the day 15 of the current month:
$ date --date="$(date +%Y-%m-15) - 1 month"
Fri Jul 15 00:00:00 CEST 2016
Then it is just a matter of using the proper format:
$ date --date="$(date +%Y-%m-15) - 1 month" "+%Y%m"
201607
To store the value in a var, just use the common var=$(command) syntax.
From GNU Coreutils → 28.7 Relative items in date strings:
The fuzz in units can cause problems with relative items. For example,
‘2003-07-31 -1 month’ might evaluate to 2003-07-01, because 2003-06-31
is an invalid date. To determine the previous month more reliably, you
can ask for the month before the 15th of the current month. For
example:
$ date -R
Thu, 31 Jul 2003 13:02:39 -0700
$ date --date='-1 month' +'Last month was %B?'
Last month was July?
$ date --date="$(date +%Y-%m-15) -1 month" +'Last month was %B!'
Last month was June!
Also, take care when manipulating dates around clock changes such as
daylight saving leaps. In a few cases these have added or subtracted
as much as 24 hours from the clock, so it is often wise to adopt
universal time by setting the TZ environment variable to ‘UTC0’ before
embarking on calendrical calculations.
I want to define time intervals like:
Each week, from Monday 12:00 a.m. to Sunday 11:59:59 p.m.
Each day from 12:00 a.m. to 11:59:59 p.m.
Each month from the first day of the month 12:00 a.m. to the last day of the month 11:59:59 p.m.
Is this possible using ISO 8601, or any other well-known standard?
You're asking for repeating periods of a week, a day and a month. The period should be defined as P1W, P1D or P1M respectively. Given an appropriate start point, I'd expect things such as the following to work:
R/2015-02-16/P1W - repeating weekly periods, starting on a known Monday.
R/2015-02-17/P1D - repeating daily periods, starting today
R/2015-02/P1M - repeating monthly periods, starting this month
These should be ISO 8601 compliant.
Currently i have missing understand on summertime, below is my context:
start summer time: June/1/2014 0h
end summer time: November/29/2014 0h
assume at the time 23h59 of November/29/2014 after passing => 0h00 November/30/2014 => the summertime will be minus 1 (-1) => 23h00 of November/29/2014 => it still under summer time (June/1/2014 0h - November/29/2014 0h)
So is my calculation above correct ?
Your misunderstanding is ignoring the fact that the time zone is part of the timestamp, and is necessary to make a timestamp in local time unambiguous.
If summer time ends at 00:00 at the beginning of November 30th, then the series of timestamps is:
2014-11-29 23:59:58 XST
2014-11-29 23:59:59 XST
2014-11-29 23:00:00 XWT
2014-11-29 23:01:01 XWT
[...]
2014-11-29 23:59:59 XWT
2014-11:30 00:00:00 XWT
(where "XST" is the summer timezone and "XWT" is the winter timezone). "2014-11-29 23:00:00 XST" and "2014-11-29 23:00:00 XWT" are two different times, one hour apart.
If you are given a local time between 2014-11-29 23:00 and 2014-11-30 00:00 without an indicator of whether it's XST or XWT, then it's impossible to turn it into a unique timestamp.
I'm querying information from a Facebook page for a small business using FQL and I'm trying to parse the business hours. The numbers I am getting back seem to represent seconds but I'm not sure when the epoch is. Wednesday and Thursday are the most confusing - open on Thursday is "57600" which would be 16 hours in seconds which would make 4pm Wednesday the epoch, but the closing hours on Wednesday - far past 4- are in the 600,000+ range.
Mon: 8:15am-12pm and 1pm - 5pm Tue: 8am-12pm and 1pm - 5pm Wed: 8am-12pm and 1pm - 9pm Thur:8am-12pm and 1pm - 5pm Fri:8am-12pm and 1pm - 5pm Sat:8am-12pm and 1pm - 5pm
<hours>
<mon_1_open>404100</mon_1_open>
<mon_1_close>417600</mon_1_close>
<tue_1_open>489600</tue_1_open>
<tue_1_close>504000</tue_1_close>
<wed_1_open>576000</wed_1_open>
<wed_1_close>590400</wed_1_close>
<thu_1_open>57600</thu_1_open>
<thu_1_close>72000</thu_1_close>
<fri_1_open>144000</fri_1_open>
<fri_1_close>158400</fri_1_close>
<sat_1_open>230400</sat_1_open>
<sat_1_close>244800</sat_1_close>
<sun_1_open>0</sun_1_open>
<sun_1_close>0</sun_1_close>
<mon_2_open>421200</mon_2_open>
<mon_2_close>435600</mon_2_close>
<tue_2_open>507600</tue_2_open>
<tue_2_close>522000</tue_2_close>
<wed_2_open>594000</wed_2_open>
<wed_2_close>622800</wed_2_close>
<thu_2_open>75600</thu_2_open>
<thu_2_close>90000</thu_2_close>
<fri_2_open>162000</fri_2_open>
<fri_2_close>176400</fri_2_close>
<sat_2_open>248400</sat_2_open>
<sat_2_close>262800</sat_2_close>
<sun_2_open>0</sun_2_open>
<sun_2_close>0</sun_2_close>
</hours>
If I change it to simply 8am-5pm Monday to Saturday I get an equally confusing response from FB
<hours>
<mon_1_open>403200</mon_1_open>
<mon_1_close>435600</mon_1_close>
<tue_1_open>489600</tue_1_open>
<tue_1_close>522000</tue_1_close>
<wed_1_open>576000</wed_1_open>
<wed_1_close>608400</wed_1_close>
<thu_1_open>57600</thu_1_open>
<thu_1_close>90000</thu_1_close>
<fri_1_open>144000</fri_1_open>
<fri_1_close>176400</fri_1_close>
<sat_1_open>230400</sat_1_open>
<sat_1_close>262800</sat_1_close>
<sun_1_open>0</sun_1_open>
<sun_1_close>0</sun_1_close>
<mon_2_open>0</mon_2_open>
<mon_2_close>0</mon_2_close>
<tue_2_open>0</tue_2_open>
<tue_2_close>0</tue_2_close>
<wed_2_open>0</wed_2_open>
<wed_2_close>0</wed_2_close>
<thu_2_open>0</thu_2_open>
<thu_2_close>0</thu_2_close>
<fri_2_open>0</fri_2_open>
<fri_2_close>0</fri_2_close>
<sat_2_open>0</sat_2_open>
<sat_2_close>0</sat_2_close>
<sun_2_open>0</sun_2_open>
<sun_2_close>0</sun_2_close>
</hours>
Am I missing some defacto standard time representation? How would someone go about parsing this as a legitimate time of day?
The Unix epoch is the time 00:00:00 UTC on 1 January 1970. Any time you see the term "epoch" used in relation to computer-based time, that's usually what it means.
In UTC, 404100 is Mon, 05 Jan 1970 16:15:00 GMT. Or, in the PST timezone, Mon, 05 Jan 1970 08:15:00 PST, which is the time you're expecting. Ignore the date; it's irrelevant, anyways.
You can test what I'm describing using this Epoch Converter.