Comments (7)
Yes, you've put your finger on something that's at the heart of this. I plan to investigate with the Go team.
from ivy.
from ivy.
There's a lot going on here, and some of it is caused by the peculiarities of the timezone database. I presume you're using Unix in some form, because otherwise I believe none of this will work.
One thing to understand (it's really subtle, and I am still missing some nuance; read on) is how time.Location works in Go. They are not time zones per se, they are locations in which time can be determined. Have a look:
% ivy
)timezone
AEST 36000
)timezone "EST"
)timezone
EST -14400
)timezone "EDT"
)timezone
EDT -14400
First, note that my timezone, AEST, prints correctly. That's a property of the system, somehow, and for the life of me I can't figure out where it comes from.
Second, note that it knows about EST and EDT but both print with the same offset, which is actually the current offset to UTC at the location in which EST is a valid time zone, e.g. New York. You can see this happening a bit in the test suite, which asks the time at the Unix epoch. The test has the wrong offset for that date, and will break when the US goes back to standard time. I should probably have commented that, and will return to it then.
Third, I can't explain why you see zero for CEST, but on my machine CEST is not a known zone so I can't get ivy into that state. I can do this though:
% ivy
)timezone "GMT"
)timezone
GMT 3600
)timezone "UTC"
)timezone
UTC 0
)timezone "Europe/Paris"
)timezone
Europe/Paris 7200
Try that and see what you get. You could also try setting the TZ environment variable and explore what happens then.
Despite this explanation, I do believe there are bugs, I just don't know how to deal with the inconsistencies in the timezone database and its interaction with what the local system says.
from ivy.
I'm using macOS. If you have a macOS machine you should be able to my reproduce my behavior:
System Settings -> General -> Date & Time
- Uncheck "Set time zone automatically using your current location"
- Set "Closest city" to "Berlin - Germany"
Now the time zone should be "Central European Summer Time" (until Oct 29).
In the following experiments I'll use this short Go program for comparison with Ivy:
package main
import (
"fmt"
"time"
)
func main() {
fmt.Println(time.Now().Zone())
}
First experiment, with my system settings (location "Berlin - Germany"):
% go run main.go
CEST 7200
% ivy -e ")timezone"
CEST 0
Here, the Go program prints what I expected, because CEST is UTC+2.
In the next experiment, the time zone database doesn't seem to know about CEST and falls back to UTC if I specify TZ=CEST:
% TZ=CEST go run main.go
UTC 0
% TZ=CEST ivy -e ")timezone"
UTC 0
In the next experiment both interpret TZ=CET as a location (which I'm not a fan of, but perhaps I'll have to accept it) and switch to CEST:
% TZ=CET go run main.go
CEST 7200
% TZ=CET ivy -e ")timezone"
CEST 0
The output of the short Go program is the consistent one.
Next experiment with TZ=GMT:
% TZ=GMT go run main.go
GMT 0
% TZ=GMT ivy -e ")timezone"
GMT 3600
In my understanding GMT is defined as UTC+0 and should always have the offset 0. However, Ivy interprets it as location "Europe/London", which is currently on British Summer Time (BST, UTC+1) rather than GMT.
from ivy.
Thanks for the good report.
I know what's wrong with GMT - I have it mapped to Europe/London instead of UTC - and that's trivial to fix.
The others require more investigation.
from ivy.
The following is my understanding when looking at this table: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones#List
-
The TZ database maps from the column "TZ identifier" (I would have called it "Location") to the current "Time zone abbreviation" along with its "UTC Offset".
-
Some "Time zone abbreviations" (such as "CET") also live a double life as "TZ identifiers" in the TZ database, which is unfortunate in my opinion.
-
There is no general lookup mechanism from a "Time zone abbreviation" string to its corresponding "UTC Offset", at least not in Go's time package. Such a lookup is required to map "CEST" to its corresponding offset. However, Ivy attempts to perform this lookup via time.LoadLocation (which is not the right lookup mechanism for this direction) and fails, ultimately defaulting to 0.
from ivy.
There is no general lookup mechanism from a "Time zone abbreviation" string to its corresponding "UTC Offset", at least not in Go's time package.
Since this lookup direction doesn't exist in the public API, I wondered if Go manages to parse "2023-09-27 18:00:00 CEST" correctly. So I ran the following program:
import (
"fmt"
"log"
"time"
)
func main() {
t, err := time.Parse("2006-01-02 15:04:05 MST", "2023-09-27 18:00:00 CEST")
if err != nil {
log.Fatal(err)
}
fmt.Println(t)
}
The output
2023-09-27 18:00:00 +0200 CEST
is correct. Then I changed my location from "Berlin - Germany" to "New York, NY - United States" in the macOS system settings, and now the output is wrong!
2023-09-27 18:00:00 +0000 CEST
I find it surprising that Go's time parsing, when provided with an explicit time zone, is dependent on the location setting.
from ivy.
Related Issues (20)
- iOS app fails to open, missing from the app store. HOT 3
- print version number HOT 2
- a way to construct multidimensional array without rho? HOT 5
- iota is inconsistent about which index it returns when there are mulitple matches HOT 4
- "unknown <nil> in references" when defining an op which uses placeholder indices
- Division vs fraction ambiguity HOT 10
- Where to as questions about Ivy ? HOT 2
- Ivy iOS App Broken as of iOS 16 + HOT 2
- support large takes (with zero fill) and large drops for matrices HOT 1
- provide enclose and disclose operations HOT 10
- help texts for `sys "date"` and `sys "time"` are swapped HOT 9
- time zone support
- encode: support non-integer rhs HOT 1
- support raising a negative number to a non-integer power
- how to recover redefined core operator ? HOT 1
- ivy: generalize matrix inverse to Moore-Penrose pseudoinverse
- test failure: stack overflow calling "gcd" HOT 2
- TestAll failure in sys.ivy
- `mix` and `split` are not inverses of each other
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ivy.