What is the extra data included in a date object? Given the following example:
time = Time.at(1392328830)
# => 2014-02-13 15:00:30 -0700
date = time.to_date
# => #<Date: 2014-02-13 ((2456702j,0s,0n),+0s,2299161j)>
What does all this represent? It's not clear from looking at the Ruby Date documentation.
((2456702j,0s,0n),+0s,2299161j)
What you're seeing is the output from Object.inspect which is a human-readable representation of an object. In the case of the Date class:
From date.rb:
# Return internal object state as a programmer-readable string.
def inspect() format('#<%s: %s,%s,%s>', self.class, #ajd, #of, #sg) end
# Return the date as a human-readable string.
#
# The format used is YYYY-MM-DD.
def to_s() strftime end
The instance variables are:
#ajd is an Astronomical Julian Day Number
#of is an offset or fraction of a day from UTC
#sg is the Day of Calendar Reform
But what do these terms mean?
1. What is an Astronomical Julian Day Number? (#ajd)
For scientific purposes, it is convenient to refer to a date simply as a day count, counting from an arbitrary initial day. The date first chosen for this was January 1, 4713 BCE. A count of days from this date is the Julian *Day* Number or Julian *Date*. This is in local time, and counts from midnight on the initial day. The stricter usage is in UTC, and counts from midday on the initial day. This is referred to in the Date class as the Astronomical *Julian* Day *Number*. In the Date class, the Astronomical Julian Day Number includes fractional days.
2. Offset from what? (#offset)
Time zones are represented as an offset from UTC, as a fraction of a day. This offset is the how much local time is later (or earlier) than UTC. UTC offset 0 is centered on England (also known as GMT). As you travel east, the offset increases until you reach the dateline in the middle of the Pacific Ocean; as you travel west, the offset decreases.
3. What is the Day of Calendar Reform? (#sg)
The Gregorian Calendar was introduced at different times in different regions. The day on which it was introduced for a particular region is the Day *of* Calendar *Reform* for that region. This is abbreviated as sg (for Start of Gregorian calendar) in the Date class.
From what I can tell, the Gregorian Calendar is calendar that self-corrects via leap years.
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
I want to calculate month between two date and output how month and any additional days by using google sheet
I use this formula to calculate month but i don't know how to calculate any additional days after a complete month.
DATEDIF(AG2,TODAY(),"M")
Quoting this reference of DATEDIF (emphasis mine): https://sheetshelp.com/datedif/
Syntax
=DATEDIF(start_date,end_date,unit)
start_date Date at which to start the calculation
end_date Date at which to end the calculation
unit Type of output. Choices are “Y”, “M”, “D”, “YM”, “YD”, or “MD”.
...
"M" – Number of whole months elapsed between start and end dates
"MD" – Number of days elapsed after the number of months shown with the “M” or “YM” unit. Can’t go higher than 30.
...
Date.new results in # -4712-01-01.
Just as per the title, what logic am i missing, why start from -4712?
https://en.wikipedia.org/wiki/Julian_day
The Julian Period is a chronological interval of 7980 years beginning 4713 BC. It has been used by historians since its introduction in 1583 to convert between different calendars. 2015 is year 6728 of the current Julian Period. The next Julian Period begins in the year 3268 AD.
The internal representation of a Date or DateTime object is an astronomical Julian date: a fractional number of days since a "time zero" in 4712 BCE.
More information are also available in the Ruby documentation for Date.
The Julian day number is in elapsed days since noon (Greenwich mean time) on January 1, 4713 BCE (in the Julian calendar).
In this document, the astronomical Julian day number is same as the original Julian day number. And the chronological Julian day number is a variation of the Julian day number. Its days begin at midnight on local time.
From Wikipedia
The Julian day number can be calculated using the following formulas (integer division is used exclusively, that is, the remainder of all divisions are dropped):
The months (M) January to December are 1 to 12. For the year (Y) astronomical year numbering is used, thus 1 BC is 0, 2 BC is −1, and 4713 BC is −4712. D is the day of the month. JDN is the Julian Day Number, which pertains to the noon occurring in the corresponding calendar date.
Can anybody explain me what it means when I have the following time:
2012-12-28T18:12:33+01:00
I'm new to the whole datetime stuff and I can't find a good explanation on the web.
Currently I'm in Holland. So does it mean:
2012-12-28T18:12:33+01:00 = 2012-12-28 19:12:33
or
2012-12-28T18:12:33+01:00 = 2012-12-28 17:12:33
or
2012-12-28T18:12:33+01:00 = 2012-12-28 18:12:33
The 2012-12-28T18:12:33+01:00 date string indicates that it is 2012-12-28 at 18:12 in the timezone that corresponds to +1 hour from UTC, which is CET timezone.
This appears to be the ISO 8601 format. The T indicates start of the time element.
Times are expressed in local time, together with a time zone offset in
hours and minutes. A time zone offset of "+hh:mm" indicates that the
date/time uses a local time zone which is "hh" hours and "mm" minutes
ahead of UTC. A time zone offset of "-hh:mm" indicates that the
date/time uses a local time zone which is "hh" hours and "mm" minutes
behind UTC.
The value you provided 2012-12-28T18:12:33+01:00 is an DateTime+Offset value in ISO8601 format, meaning "December 12th, 2013 at 18:12:33, one hour ahead of UTC".
The +01:00 portion represents an offset, not a time zone. See TimeZone != Offset.
The time zone for Holland is either Europe/Amsterdam in the IANA/Olson database, or the entry in the Windows database that has the Id of W. Europe Standard Time and the English display name of "(UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna".
This zone is in the +01:00 offset during part of the year, and uses the +02:00 offset during European Summer Time.
Just because you have +01:00 in December, does not mean that is the correct offset to use year-round. It also does not tell you that the timestamp is in Holland. There are several other time zones that use the same offset, and not always at the same times of year.
To convert from one time zone to another, you need to first apply the offset you have. Use the inverse of the sign you have. Since you have +01:00, you would subtract an hour to get the UTC time of 17:12:33. Then you need to know what the correct offset is for the target time zone at that time of year. For that, you need a time zone database.
International Standard ISO 8601 specifies numeric representations of date and time.
YYYY-MM-DDThh:mm:ss.sTZD (eg 1997-07-16T19:20:30.45+01:00)
where:
YYYY = four-digit year
MM = two-digit month (01=January, etc.)
DD = two-digit day of month (01 through 31)
hh = two digits of hour (00 through 23) (am/pm NOT allowed)
mm = two digits of minute (00 through 59)
ss = two digits of second (00 through 59)
s = one or more digits representing a decimal fraction of a second
TZD = time zone designator (Z or +hh:mm or -hh:mm)
Times are expressed in UTC (Coordinated Universal Time), with a special UTC designator ("Z").
Times are expressed in local time, together with a time zone offset in hours and minutes. A time zone offset of "+hh:mm" indicates that the date/time uses a local time zone which is "hh" hours and "mm" minutes ahead of UTC. A time zone offset of "-hh:mm" indicates that the date/time uses a local time zone which is "hh" hours and "mm" minutes behind UTC.
In your case: 2012-12-28T18:12:33+01:00 = 2012-12-28 18:12:33 is true. Meaning the time in Holland is 18:12 and you are 1 hour ahead of UTC.
I understand that it's pretty easy to display local time to a user given an offset from GMT for the timezone (e.g. -7 hours for Pacific Daylight Time).
But, what if I want to continue to display the correct local time for a long period of time (say 1 year). Given just an offset from GMT, you do not know what timezone the user is in. E.g. given -7, the user may live in the US or in Canada (or in some other country). These countries my have different local times at different points of the year (e.g. if the US changes to daylight time in March and CA in April).
My question is, is the above paragraph correct? Is there a standard way to take a GMT offset and make a good guess as to which timezone the user is in?
Your conclusion is correct: There is no reliable way to identify a time zone from an offset-from-UTC.
For your example of an offset of -07:00, I count about three dozen possible time zones in the current list including: America/Boise, America/Chihuahua, and America/Edmonton.
A time zone is actually a collection of offsets, recording changes made over time with a certain offset used in that region for a certain period of time but then changed over another certain period of time.
For example, in America/Los_Angeles part of each year has an offset of -08:00 while another part of the year has -07:00. So that time zone is accumulating a history of at least two offsets per annum. In contrast, the neighboring region using the time zone America/Phoenix is not accumulating changes in its offset, having retained the same -07:00 offset for decades.
So we have a many-to-many relationship between offsets and time zones. An offset may appear in one or more time zones. And each time zone can have one or more offsets (having changed over history).
Include time zone name
This is why the designers of the java.time class ZonedDateTime have taken the liberty of having its toString method extend the standard ISO 8601 format using only offsets to also append the name of the time zone in square brackets.
For example, instead of simply generating the standard format: 2007-12-03T10:15:30+01:00, the class generates 2007-12-03T10:15:30+01:00[Europe/Paris] with the name of the zone Europe/Paris appended.
ZonedDateTime.now( ZoneId.of( "America/Montreal" ) )
.toString()
2007-12-03T10:15:30+01:00[Europe/Paris]
I hope this practice of appending the time zone name catches on. The lack of time zone name is a surprising omission by the standards committees that otherwise did an outstanding job in designing ISO 8601.
You can guess about the time zone using clues from the context of your business scenario. But I advise against that. Guessing is risky, especially because politicians around the world have a penchant for frequently re-defining time zones.
UTC
The best practice in storing, serializing, and exchanging date-time values is generally to adjust into UTC. Assuming a date-time library’s tzdata is up-to-date, adjusting into UTC provides a reliable value that is always correct and unambiguous.
In Java, for example, that means using or extracting an Instant object. The Instant class represents a moment on the timeline in UTC with a resolution of nanoseconds (up to nine (9) digits of a decimal fraction).
Instant instant = Instant.now();
…or…
ZonedDateTime zdt = ZonedDateTime.now( ZoneId.of( "America/Montreal" ) );
Instant instant = zdt.toInstant();
The standard ISO 8601 formatted string representing such a value uses a Z as short for Zulu and meaning UTC.
2007-12-03T09:15:30Z
OffsetDateTime
If you are given a string representing a date-time with only an offset, parse it as a OffsetDateTime object.
OffsetDateTime odt = OffsetDateTime.parse( "2007-12-03T10:15:30+01:00" );
odt.toString(): 2007-12-03T10:15:30+01:00
From there you can extract a value in UTC, an Instant.
Instant instant = odt.toInstant();
instant.toString(): 2007-12-03T09:15:30Z
Or you can adjust into a desired time zone to get the same moment as a ZonedDateTime object.
ZoneId z = ZoneId.of( "Asia/Kolkata" );
ZonedDateTime zdt = odt.atZoneSameInstant( z );
zdt.toString(): 2007-12-03T14:45:30+05:30[Asia/Kolkata]
Terminology: “local”
I suggest you avoid the term “local” when referring to a date-time adjusted into a region’s particular wall-clock time. The word “local” in the java.time classes and in other contexts means any locality, rather than a particular locality. A local date-time is not a specific moment on the timeline, only a rough idea about a range of possible moments.
For example the local date-time of the beginning of Christmas this year is 2017-12-25T00:00:00, but that moment of midnight is much earlier in Auckland than in Kolkata, and still hours later in Paris, while even more hours later in Montréal.
I suggest instead you use the terms zoned or wall-clock time when you mean a specific moment seen through the lens of a particular time zone.
Tip: Offset literals
The Question happened to use the letters -7 when referring to an offset. I suggest always:
Using double-digits with padding zero, as required by ISO 8601
Using both hour and minutes, as expected by some libraries and formats.
So use -07:00 rather than -7.