I need some information about this date '2015-05-12T00:00:00Z'. What does it mean 'T' and 'Z'? Anyone can help me?I don't know how they mean. I need to convert this data in another format
ISO 8601
The ISO 8601 standard defines formats for representing date-time values as text.
The T is just a marker for where the time part begins.
The Z is an abbreviation of +00:00, meaning UTC (an offset of zero hour-minutes-seconds). Pronounced “Zulu” per military and aviation tradition.
From the Wikipedia article on ISO 8601
A single point in time can be represented by concatenating a complete date expression, the letter T as a delimiter, and a valid time expression. For example "2007-04-05T14:30".
[...]
If the time is in UTC, add a Z directly after the time without a space. Z is the zone designator for the zero UTC offset. "09:30 UTC" is therefore represented as "09:30Z" or "0930Z". "14:45:15 UTC" would be "14:45:15Z" or "144515Z".
Related
I have been writing unit tests for a class in our codebase that basically converts date, time values from std::string to std::chrono::time_point and vice versa, for different kinds of timestamps (yyyy-mm-dd , hh:mm:ss.ms etc).
One way I tried to test whether a std::chrono::system_clock::time_point returned by a function in our codebase as the same as one created in the unit tests was to do something like this -
std::chrono::system_clock::time_point m_TimePoint{}; // == Clock's epoch
auto foo = convertToString(n_TimePoint); //foo is std::string
auto bar = getTimePoint(foo);
ASSERT_EQ(m_TimePoint, bar);
This was on Ubuntu , now the constructor should return a time point as UTC Jan 1 00:00:00 1970. Now when I used ctime() to see the textual representation of the epoch it returned Dec 31 19:00:00 1969. I was puzzled and checked that EST(my system timezone) is equal to UTC-5.
Once I created the object as -
std::chrono::duration d{0};
d += std::chrono::hours(5);
std::chrono::system_clock::time_point m_TimePoint{d}; //== clock epoch + 5 hours
All worked fine.
My question is it possible for the system clock epoch to be adjusted based on the system timezone?
There's two answers to this question, and I'll try to hit both of them.
system_clock was introduced in C++11, and its epoch was left unspecified. So the technical answer to your question is: yes, it is possible for the system_clock epoch to be adjusted based on the system timezone.
But that's not the end of the story.
There's only a few implementations of system_clock, and all of them model Unix Time. Unix Time is a measure of time duration since 1970-01-01 00:00:00 UTC, excluding leap seconds. It is not dependent on the system timezone.
The C++20 spec standardizes this existing practice.
So from a practical standpoint, the answer to your question is: no, it is not possible for the system_clock epoch to be adjusted based on the system timezone.
One thing that could be tripping you up is that system_clock typically counts time in units finer than milliseconds. It varies from platform to platform, and you can inspect what it is with system_clock::duration::period::num and system_clock::duration::period::den. These are two compile-time integral constants that form a fraction, n/d which describes the length of time in seconds that system_clock is measuring. For Ubuntu my guess would be this forms the fraction 1/1'000'000'000, or nanoseconds.
You can get milliseconds (or whatever unit you want) out of system_clock::time_point with:
auto tp = time_point_cast<milliseconds>(system_clock::now());
I just started to learn Go by following a tutorial video on Udemy, and I tried to print the current time as below
import (
"fmt"
"time"
)
func main(){
t := time.Now()
fmt.Println(t)
}
And I get a very long text as the output as below
2018-07-04 12:03:07.2911671 +0800 +08 m=+0.002000201
I was expecting to get only the +0800 followed by a timeZone and that should be the end of it. The expected output is shown below and as it was shown in the tutorial video, too. But for me, the result is in much longer form.
2018-07-04 12:03:07.2911671 +0530 IST
The question is, why does the same command date.Now() return different formats between the instructor's program and mine? Why is there no specific format being set, shouldn't a standardize/base format being returned instead?
The question is, why the same command date.Now() is returning different format between the instructor's program and mine?
Because the tutorial was created before the release of Go 1.9. As of Go 1.9, monotonic clock support was added to the time.Time struct, which added those extra fields.
For normal usage, you should always output time using the Format function, rather than outputting the raw data. This will produce more useful output, and be protected against any future additions to the underlying type.
Your Udemy tutorial video is out-of-date. Go is continually updated. For example, a monotonic clock bug fix:
Go 1.9 Release Notes (August 2017)
Transparent Monotonic Time support
The time package now transparently tracks monotonic time in each Time
value, making computing durations between two Time values a safe
operation in the presence of wall clock adjustments. See the package
docs and design document for details.
As always, there are various minor changes and updates to the library,
made with the Go 1 promise of compatibility in mind.
time
If a Time value has a monotonic clock reading, its string
representation (as returned by String) now includes a final field
"m=±value", where value is the monotonic clock reading formatted as a
decimal number of seconds.
Package time
import "time"
The Time returned by time.Now contains a monotonic clock reading. If
Time t has a monotonic clock reading, t.Add adds the same duration to
both the wall clock and monotonic clock readings to compute the
result. Because t.AddDate(y, m, d), t.Round(d), and t.Truncate(d) are
wall time computations, they always strip any monotonic clock reading
from their results. Because t.In, t.Local, and t.UTC are used for
their effect on the interpretation of the wall time, they also strip
any monotonic clock reading from their results. The canonical way to
strip a monotonic clock reading is to use t = t.Round(0).
fmt.Println(t) uses a debugging format so it prints all the underlying time.Time fields.
The canonical way to strip a monotonic clock reading is to use t =
t.Round(0).
For example,
package main
import (
"fmt"
"time"
)
func main() {
t := time.Now()
fmt.Println(t)
fmt.Println(t.Round(0))
t2 := time.Now().Round(0)
fmt.Println(t2)
}
Playground: https://play.golang.org/p/p_pjRWRB8_y
Output:
2009-11-10 23:00:00 +0000 UTC m=+0.000000001
2009-11-10 23:00:00 +0000 UTC
2009-11-10 23:00:00 +0000 UTC
The +08 is the string returned by t.Location().String(). Locations are given a string on creation which is used to identify it. It could be IST, or it can be "+08" or any other string you can think of.
The m=+0.002000201 is the monotonic clock. It is used for more accurate durations. For more information on Go's monotonic clock implementations, see https://golang.org/pkg/time/#hdr-Monotonic_Clocks.
As for the reason the monotonic clock shows up in t.String():
For debugging, the result of t.String does include the monotonic clock reading if present. If t != u because of different monotonic clock readings, that difference will be visible when printing t.String() and u.String().
The d3 documentation states that the (none) format type works "like g, but trims insignificant trailing zeros". The g format type uses "either decimal or exponent notation, rounded to significant digits."
Mike Bostock explained that "The none format type trims trailing zeros, but the precision is interpreted as significant digits rather than the number of digits past the decimal point."
If I use d3.format('.2')(2.0), I get 2 (trailing zeros are dropped).
But when I use d3.format('.2')(2.001) the result is 2.001: No rounding happens. I would have expected the result to be 2.0 (rounding to two significant digits, but keeping the zero), or 2 (rounding to two significant digits, then dropping the zero).
Is this a bug, or am I misunderstanding the syntax?
This happened because I was using an old version of d3 (3.5.17, which ships with the current version of plot.ly 1.27.1).
In that version of d3, the (none) format type doesn't exist. It was introduced in 2015.
I've just been reading this mind-blowing and hilarious post about some common falsehoods regarding time. Number forty is:
Every integer is a theoretical possible year
This implies that every integer is not a theoretical possible year. What is the negative case here? What integer is not a theoretically possible year?
Depending on the context, 0 is not a valid year number. In the Gregorian calendar we're currently using (and in its predecessor, the Julian calendar), the year 1 (CE/AD) was immediately preceded by the year -1 (1 BCE/BC). (For dates before the Gregorian calendar was introduced, we can use either the Julian calendar or the proleptic Gregorian calendar).
In a programming context, this may or may not be directly relevant. Different languages, libraries, and frameworks represent years in different ways. ISO 8601, for example, supports years from 0000 to 9999, where 0000 is 1 BCE; wider ranges can be supported by mutual agreement. Some implementations of the C standard library can only represent times from about 1901 to 2038; others, using 64-bit time_t can represent a much wider range, and typically treat -1, 0, and 1 as consecutive years.
Ultimately you'll need to check the documentation for whatever language/library/framework you're using.
Does anyone know what this format line means in fortran:
FORMAT(1x,F7.0,2x,1P10E11.3)
I know the first part is one repetition of float number but I don't understand how many exponential data points are read in the second part and what that P is for.
The P format shifts the decimal point. The behavior is different on input and output. On output, applied to an E format, it shifts the decimal point of the value before the exponent and changes the values of the exponent such that the value of the number is unchanged. If plain E would output 0.123E+3, 1PE will output 1.230E+2. On input it changes the value read -- use with great caution or not at all. Another "gotcha" is that P stays in effect for the rest of the format, until another P specifier appears in the format, e.g., 0P to reset. One of the newer G, ES or EN formats are generally better than the combination of P and E.