In golang documentation, it is stated that :
These are predefined layouts for use in Time.Format and Time.Parse.
The reference time used in the layouts is:
Mon Jan 2 15:04:05 MST 2006
which is Unix time 1136239445
What is the origin of this specific date ?
That's explained immediately after the section you quoted:
Since MST is GMT-0700, the reference time can be thought of as
01/02 03:04:05PM '06 -0700
It's a simple increasing sequence: 01 02 03 04 05 (PM) 06 07.
Using 03:04 PM rather than 03:04 AM makes it possible to show the two time representations 15:04 and 03:04PM more clearly (this is speculation on my part).
It is just the numbers 1 2 3 4 5 6 7
1: month (January, Jan, 01, etc)
2: day
3: hour (15 is 3pm on a 24 hour clock)
4: minute
5: second
6: year (2006)
7: timezone (GMT-7 is MST)
Related
When I find a time zone format like
"CET-1CEST,M3.5.0,M10.5.0/3"
what's the meaning of the three field? I understand the CET-1CEST but what about the last two M3.5.0 and M10.5.0/3?
I found this format in this tutorial for ESP32 NTP Time and in this list.
Well, if you scroll a little down, you'll notice that such string is called a timezone String (at least in the article). After a quick search, I came across this link, where the meaning of such string is found:
std offset dst [offset],start[/time],end[/time]
For example,
Here are some example TZ values, including the appropriate Daylight Saving Time and its dates of applicability. In North American Eastern Standard Time (EST) and Eastern Daylight Time (EDT), the normal offset from UTC is 5 hours; since this is west of the prime meridian, the sign is positive. Summer time begins on March’s second Sunday at 2:00am, and ends on November’s first Sunday at 2:00am.
EST+5EDT,M3.2.0/2,M11.1.0/2
So for CET-1CEST,M3.5.0,M10.5.0/3:
The standard timezone is CET (Central European Time)
The offset from UTC is −1
The DST timezone is CEST (Central European Summer Time)
DST starts at:
3: the third month of the year (March)
5: the last…
0: …Sunday of the month
(no time specifier, defaults to 2 AM)
DST ends at:
10: the tenth month of the year (October)
5: the last…
0: …Sunday of the month
3: at 3 AM
could someone explain me what is this Time Format?
1381039499
I do not know how should I have to change it to normal Time format
My guess is that it's the Unix Epoc, defined as the number of seconds that have elapsed since 00:00:00 Coordinated Universal Time (UTC), Thursday, 1 January 1970.
According to this site, that is the Unix timestamp for:
Sun, 06 Oct 2013 06:04:59 GMT.
Most programming languages have a function to convert to/from Unix timestamps, but the correct way to do this will obviously vary between them.
I have row of data like this that represent a business opening hours
day / opentime / closetime / isOpen
0 09:00:00 17:00:00 true
1 09:00:00 17:00:00 true
2 08:00:00 17:00:00 true
3 09:00:00 17:00:00 true
4 09:00:00 17:00:00 true
5 false
6 09:00:00 17:00:00 true
with day being an Integer from 0-6 (mon to sunday) and iOpen
Before Re-inventing the wheel and start thinking on a new algorithm I would like to know if there already some algo that would do something similar to this:
MON - TUE 9am - 5pm
WED 8am - 5pm
THU - FRI 9am - 5pm
SUN 9am - 5pm
basically grouping the day that have the opening and closing time together ?
I'm not asking for a ready to go algorithm but more of an advice to where to look if there is already something similar that has been done.
ps: bonus question. Is the way I store the data efficient to achieve my goal ?
This is a fairly straightforward algorithm. Just write down in code what you would do as a human.
As a human, when I look at the data you give me, I start with Monday, and I write down the open/close times on a sheet of paper and write "Monday" next to them. Then I look at Tuesday. If Tuesday has the same open/close times as the previous day, then I simply go to where the time was already written on my paper and add "Tuesday" right next to Monday. I keep doing this until I find an open/close time that is not the same as the previous day's. In that case, I go to a new line on my paper and write down the new open/close times and continue on like this until the end.
If I were to program this in C, I would use an array of structs, where the struct merely had the open time, the close time, and an array of character arrays (ie, an array of strings) to store the dates associated with those hours. (Note: there could be more efficient ways of storing this, but this seems good enough for your purposes)
I have an idea for a story in which certain events happen repeatedly throughout the year of calendar dates that perfectly match each other for example 2011, 2005, 1994 one could replace these calendars with each other
I would like to be able to find calendar years past and future
If someone could help me please as I have no programming ability
Thanks in advance
Check Wikipedia.
You only need to compare the day of the week on which the first day of the year falls, and compare leap years and non-leap years separately (they will obviously differ). If the first day is the same and the days in the year are the same, so will the whole year be the same.
With this reduction, we need to first know what is a leap year. From wikipedia, the algorithm is
if year modulo 400 is 0
then is_leap_year
else if year modulo 100 is 0
then not_leap_year
else if year modulo 4 is 0
then is_leap_year
else
not_leap_year
Then we need to calculate the first day of the year. Before we start, we need a grounding. Let's take 2000, which starts on a Saturday. Every year we move forward, we move forward one day in the week except if the year follows a leap year in which case we move forward two days.
Let's walk through an example. 2000 starts on Saturday. 2001 starts on a Monday, 2 days later because 2000 is a leap year. 2002 starts on Tuesday. 2003 on a Wednesday. 2004 on a Thursday. 2005 on a Saturday, because 2004 is a leap year. From this we see that 2000 and 2005 start on the same day of the week, but the one is a leap year while the other is not. If we continue we'll find 2011 starts on a Saturday, and is therefore identical to 2005.
We can work backwards in similar fashion to find years in the past, or we can just choose an earlier starting year.
Dominical letter B: ... 1910 1921 1927 1938 1949 1955 1966 1977 1983 1994 2005 2011 2022 2033 2039 2050 2061 2067 2078 2089 2095 ...
Be careful about going back before 1752 and 1582, where 11 and 10 days were dropped from the calendar, respectively. see dataandtime.com. Otherwise there are exactly 14 possible calendars ... Half with a Feb 29th, half without. Each pair of calendars starts on a different day of the week. There should be an excel spreadsheet out there (its easy enough to generate one) that maps the years since 1752 into one of 14 columns.
2016 ends on the same days of the week as 1994, 2005 and 2011, but 2016 starts on Friday (leap year), while all the other years start on Saturday, therefore we need to wait until 2022 before the dates in 2011 match up again.
The Date constructor in JavaScript/ECMAScript/JScript allows passing the number of milliseconds since midnight, 1/1/1970. Nowhere can I find documentation whether this is midnight in the client machine's timezone, or midnight GMT. Which is it? Can it be relied on between different browsers and versions? Is this officially documented anywhere?
From the ECMAScript specification:
Time is measured in ECMAScript in
milliseconds since 01 January, 1970
UTC. In time values leap seconds are
ignored. It is assumed that there are
exactly 86,400,000 milliseconds per
day. ECMAScript Number values can
represent all integers from
–9,007,199,254,740,991 to
9,007,199,254,740,991; this range
suffices to measure times to
millisecond precision for any instant
that is within approximately 285,616
years, either forward or backward,
from 01 January, 1970 UTC.
The actual
range of times supported by ECMAScript
Date objects is slightly smaller:
exactly –100,000,000 days to
100,000,000 days measured relative to
midnight at the beginning of 01
January, 1970 UTC. This gives a range
of 8,640,000,000,000,000 milliseconds
to either side of 01 January, 1970
UTC.
The exact moment of midnight at
the beginning of 01 January, 1970 UTC
is represented by the value +0.
So to answer your question, it's Coordinated Universal Time.