Regarding the xsd:date, is the Z required or implied for an xsd:date datatype?
For example, are both 2001-06-03 and 2001-06-03Z valid and are both assumed to be UTC format?
[-]CCYY-MM-DD[Z|(+|-)hh:mm] is the xsd:date value space. As you can see the time zone etc are optional.
If Z is present then only it is considered UTC. If you doesn't specify Z then it is considered undetermined.
Read this and this for more details. Below are examples with comments taken from link 2.
2004-04-12 April 12, 2004
-0045-01-01 January 1, 45 BC
12004-04-12 April 12, 12004
2004-04-12-05:00 April 12, 2004, US Eastern Standard Time, which is 5 hours behind
Coordinated Universal Time (UTC)
2004-04-12Z April 12, 2004, Coordinated Universal Time (UTC)
Related
On this page: https://en.wikipedia.org/wiki/ISO_8601
... it says:
2020-01-28T08:17:09+00:00
On my computer, running Windows 10, there is a locale called "english - World" (en_001). It's supposed to be some kind of "international compromise" locale, for use when you can't determine the exact locale. This is what it looks like and what I expected based on what I know about international standards/compromises:
Actual date format:
28/01/2020, 10:17 am
Expected date format:
2020-01-28T08:17:09+00:00
or
2020-01-28 08:17
Actual number format:
123,456,789.99
Expected number format:
123 456 789.99
Actual money sum format:
SEK 123,456,789.99
Expected money sum format:
123 456 789.99 SEK
Actual percent format:
99.99%
Expected percent format:
99.99 %
Why is the "World" locale so US-centric and seemingly entirely ignores the ISO standard linked to? It's definitely not supposed to use commas for thousands separators as this is very much US/UK-specific! And Wikipedia specifically states that percentages use a space in international context.
Well, the locale "en-001" is first of all using English, see the prefix "en". And the English-speaking parts of the world does not use ISO-8601-formats but other English-specific "traditional" formats.
ISO-8601 is mainly intended for the technical exchange of date-time-informations. Therefore this standard emphasizes the sortability of date-times in textual form, hence the date-time-components in ISO-8601 follow the order year-month-day-hour(24)-minute-second.
On the other Hand, "en-001" is rather intended for English speakers without exactly specifying the concrete English-speaking country, that means: It can be US, UK, Australia, South Africa etc. Of course, due to the economic and military power of US, the US-standards dominate here.
I have a given time string 14:00 and want to subtract 5 Minutes.
How can this be done in bash?
Gives me a datetime object: date -d "14:00" +'%H:%M' -> 14:00
I tried subtract: date -d "14:00 - 5min" +'%H:%M'
-> Gives 21:01. But Why?
Desired result if of course: 13:55.
The following works:
$ date -d "14:00 5 minutes ago" +'%H:%M'
13:55
I can't explain why though.
From the info page for gnu date:
Our units of temporal measurement, from seconds on up to months,
are so complicated, asymmetrical and disjunctive so as to make
coherent mental reckoning in time all but impossible. Indeed, had
some tyrannical god contrived to enslave our minds to time, to make
it all but impossible for us to escape subjection to sodden
routines and unpleasant surprises, he could hardly have done better
than handing down our present system. It is like a set of
trapezoidal building blocks, with no vertical or horizontal
surfaces, like a language in which the simplest thought demands
ornate constructions, useless particles and lengthy
circumlocutions. Unlike the more successful patterns of language
and science, which enable us to face experience boldly or at least
level-headedly, our system of temporal calculation silently and
persistently encourages our terror of time.
—Robert Grudin, ‘Time and the Art of Living’.
.
and, more relevantly:
The time may alternatively be followed by a time zone correction,
expressed as ‘SHHMM’, where S is ‘+’ or ‘-’, HH is a number of zone
hours and MM is a number of zone minutes
Your attempt to perform arithmetic is failing, and date is trying to parse the expression "- 5min" as a time zone correction.
I'm writing a program that receives data in the form of GPRMC NMEA sentences and outputs it as specified by GTFS-realtime.
GTFS-realtime wants a "timestamp" value, and describes it as such:
Moment at which the vehicle's position was measured. In POSIX time (i.e., number of seconds since January 1st 1970 00:00:00 UTC).
Here's a complete GPRMC sentence, with the relevant fields bolded:
$GPRMC,123519,A,4807.038,N,01131.000,E,022.4,084.4,230394,003.1,W*6A
The above tells me that the reading was taken at 12:35:19 on 23/03/94.
According to http://www.epochconverter.com/, this date and time is represented as 767104519 in POSIX time.
Using Erlang, what is the best way to go about deriving a POSIX timestamp from a GPRMC NMEA sentence?
How do you convert epoch time (unix timestamp) to standard time in D? Is there a way to customize the format?
You really should separate questions out, not ask two completely different questions at the same time.
How do you convert epoch time (unix timestamp) to standard time in D?
If you need to convert from unix time to SysTime's "std time," then you use unixTimeToStdTime:
assert(unixTimeToStdTime(0) == (Date(1970, 1, 1) - Date.init).total!"hnsecs");
So, if you do SysTime(unixTimeToStdTime(0)), you'll get a SysTime in your local time zone at the point in time when it was midnight, January 1st 1970 in UTC (i.e. the epoch time). Unlike the other SysTime constructors, it does not treat the time it's given as being in the timezone that it's given. Rather, it just sets its stdTime to the given value, and it's timezone to the given value. So, to construct an identical SysTime with the other constructors, you'd do something like
auto epochInLocalTime = SysTime(Date(1970, 1, 1), UTC()).toLocalTime();
If you want to convert in the opposite direction, stdTimeToUnixTime will convert a std time to a unix time. However, SysTime has toUnixTime on it, making it so that you generally don't need stdTimeToUnixTime.
time_t epoch = epochInLocalTime.toUnixTime();
However, one thing to be aware of is the fact that std.datetime truly deals with unix time - time_t is always considered to be in UTC. The reason that this matters is that for some inexplicable reason, Windows applies the local time's DST to time_t so that the UTC offset never changes, which means that it's wrong for a good chunk of the year. It works with all of the Microsoft's functions which use time_t, because they expect that nonsense, but you'll have interoperability problems if you try and use a Windows time_t with another box or with a library like std.datetime which actually uses time_t correctly.
Is there a way to customize the format?
You mean that you're looking for a way to provide a user-defined format for a string representing the time (like C's strftime)? std.datetime doesn't have that yet. The API still needs to be designed for it. Some discussion has taken place, but it hasn't been settled on yet. So, it'll happen eventually, but it could be a while.
In the interim, you have toISOString, toISOExtString, and toSimpleString, which use the ISO format, the ISO extended format, and Boost's simple string format respectively. In general, I'd suggest using toISOExtString, because it's both easily read by humans and standard. It's also generally best to put it in UTC (e.g. sysTime.toUTC()) when communicating with other computers (as opposed to printing it out for humans), because then the time zone is part of it, unlike with LocalTime, which doesn't append the time zone.
If you haven't read this article on std.datetime yet, then I suggest that you do, since it should give you a good overview of the module and how to use it.
I'm not familiar with D, but according to std.datetime, you could use these steps
long unixTimeToStdTime(time_t)
struct SysTime(long stdTime)
SysTime.dayOfGregorianCal()
struct Date(int day)
Date.toISOExtString()
Many programming languages that use IEEE 754 doubles provide a library function to convert those doubles to strings. For example, C has sprintf, C++ has stringstream, Java has Double.toString, etc.
Internally, how are these functions implemented? That is, what algorithm(s) are they using to convert the double into a string representation, given that they are often subject to programmer-chosen precision limitations?
Thanks!
The code used by various software environments to convert floating-point numbers to string representations is typically based on the following publications (the work by Steele and White is particularly frequently cited):
Jerome T. Coonen: "An Implementation Guide to a Proposed Standard for Floating-Point Arithmetic." Computer, Vol. 13, No. 1, January 1980, pp. 68-79
Guy. L. Steele Jr. and J. L. White: "How to print floating-point numbers accurately". In proceedings of ACM SIGPLAN '90 Conference on Programming Language Design and Implementation, White Plains, New York, June 1990, pp. 112-126
David M. Gay: "Correctly rounded binary-decimal and decimal-binary conversions." Technical Report 90-10, AT&T Bell Laboratories, November 1990.
Some relevant followup work:
Robert G. Burger and R. Kent Dybvig: "Printing floating-point numbers quickly and accurately." In proceedings of ACM SIGPLAN 1996 conference on Programming Language Design and Implementation, Philadelphia, PA, USA, May 1996, pp. 108-116
Guy L. Steele Jr. and Jon L. White: "Retrospective: How to print floating-point numbers accurately." ACM SIGPLAN Notices, Vol. 39, No. 4, April 2004, pp. 372–389
Florian Loitsch: "Printing floating-point numbers quickly and accurately with integers." In proceedings of 2010 ACM SIGPLAN Conference on Programming Language Design and Implementation, Toronto, ON, Canada, June 2010, pp. 233-243
Marc Andrysco, Ranjit Jhala, and Sorin Lerner: "Printing floating-point numbers: a faster, always correct method." ACM SIGPLAN Notices, Vol. 51, No. 1, January 2016, pp. 555-567
Ulf Adams: "Ryū: fast float-to-string conversion." ACM SIGPLAN Notices, Vol. 53, No. 4, April 2018, pp. 270-282
I believe you are looking for Printing Floating-Point Numbers Quickly and Accurately
I found that link on another post: here.
See Ryan Juckett's Printing Floating-Point Numbers (2014), which describes history and implementations of floating-point to string conversions. In this four-part post, Ryan also provides a C++ implementation of Dragon4 based on Steele and White (1990), which is an efficient algorithm to convert a binary number in floating point format to a decimal number in string format.
You can also see a C implementation of Ryan's Dragon4 for Numpy here, and use it within Python/Numpy 1.14 format_float_positional and format_float_scientific functions.
In 2018, an algorithm/library Ryu was published, with bindings in many modern programming languages (C, Java, C++, C#, Scala, Rust, Julia, Go, ...)
For most example languages you quote the source is freely consultable online as they're available in open source.
For Java, the class java.lang.Double delegates this work to sun.misc.FloatingDecimal. Check out its constructor and toJavaFormatString() method.
For C, glibc is always a good example, and there we see that floating point output is located in its own source file.