Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

time.add_days(1) jumps from 2013-05-01 to 1970-01-02 #17162

Closed
gmlewis opened this issue Jan 29, 2023 · 2 comments
Closed

time.add_days(1) jumps from 2013-05-01 to 1970-01-02 #17162

gmlewis opened this issue Jan 29, 2023 · 2 comments
Labels
Bug This tag is applied to issues which reports bugs. Status: Confirmed This bug has been confirmed to be valid by a contributor.

Comments

@gmlewis
Copy link
Contributor

gmlewis commented Jan 29, 2023

Describe the bug

Using V 0.3.2 9a86456, I wrote the following program:

module main

import time

fn main() {
	t := time.Time{
		year: 2013
		month: 5
		day: 1
	}
	println('BEFORE: ${t} is a ${t.long_weekday_str()}: ${t.debug()}')
	t2 := t.add_days(1)
	println('AFTER: ${t2} is a ${t2.long_weekday_str()}: ${t2.debug()}')
}

and ran it on my Linux Mint Cinnamon 20.3 box:

v version && v run bug.v
V 0.3.2 9a86456
BEFORE: 2013-05-01 00:00:00 is a Wednesday: Time{ year: 2013 month: 05 day: 01 hour: 00 minute: 00 second: 00 microsecond: 000000 unix: 0000000 }
AFTER: 1970-01-02 00:00:00 is a Friday: Time{ year: 1970 month: 01 day: 02 hour: 00 minute: 00 second: 00 microsecond: 000000 unix: 0086400 }

Expected Behavior

I expected to see 2013-05-02.

Current Behavior

I got: 1970-01-02.

Reproduction Steps

module main

import time

fn main() {
	t := time.Time{
		year: 2013
		month: 5
		day: 1
	}
	println('BEFORE: ${t} is a ${t.long_weekday_str()}: ${t.debug()}')
	t2 := t.add_days(1)
	println('AFTER: ${t2} is a ${t2.long_weekday_str()}: ${t2.debug()}')
}

Possible Solution

No response

Additional Information/Context

No response

V version

V 0.3.2 9a86456

Environment details (OS name and version, etc.)

OS: linux, Linux Mint 20.3
Processor: 4 cpus, 64bit, little endian, Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz
CC version: cc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0

getwd: /home/glenn/exercism/vlang/meetup
vmodules: /home/glenn/.vmodules
vroot: /home/glenn/src/github.com/vlang/v
vexe: /home/glenn/src/github.com/vlang/v/v
vexe mtime: 2023-01-29 02:00:22
is vroot writable: true
is vmodules writable: true
V full version: V 0.3.2 148d578.9a86456

Git version: git version 2.25.1
Git vroot status: weekly.2022.29-1224-g9a864563 (6 commit(s) behind V master)
.git/config present: true
thirdparty/tcc status: thirdparty-linux-amd64 12f392c3
@gmlewis gmlewis added the Bug This tag is applied to issues which reports bugs. label Jan 29, 2023
@JalonSolov JalonSolov added the Status: Confirmed This bug has been confirmed to be valid by a contributor. label Jan 30, 2023
@JalonSolov
Copy link
Contributor

This is a case of V's default initialization combined with no constructors, is causing a problem.

The key is in the output: unix: 0000000 for your initial Time.

add_days adds values to the unix field, which in this case is 0, instead of a representation of the number of seconds from 1970-01-01. So when it adds a day, you get 1970-01-02, which is what you saw for the value in t2.

This one will be... interesting to fix.

@yuyi98
Copy link
Member

yuyi98 commented Jan 31, 2023

module main

import time

fn main() {
	t := time.new_time(
		year: 2013
		month: 5
		day: 1
	)
	println('BEFORE: ${t} is a ${t.long_weekday_str()}: ${t.debug()}')
	t2 := t.add_days(1)
	println('AFTER: ${t2} is a ${t2.long_weekday_str()}: ${t2.debug()}')
}

PS D:\Test\v\tt1> v run .
BEFORE: 2013-05-01 00:00:00 is a Wednesday: Time{ year: 2013 month: 05 day: 01 hour: 00 minute: 00 second: 00 microsecond: 000000 unix: 1367366400 }    
AFTER: 2013-05-02 00:00:00 is a Thursday: Time{ year: 2013 month: 05 day: 02 hour: 00 minute: 00 second: 00 microsecond: 000000 unix: 1367452800 }  

We should disallow the direct use of structs to initialize values.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug This tag is applied to issues which reports bugs. Status: Confirmed This bug has been confirmed to be valid by a contributor.
Projects
None yet
Development

No branches or pull requests

4 participants